Implementation and Simulation of Real time Pulse Processing Functions

Transcription

1 Implementation and Simulation of Real time Pulse Processing Functions Tyler Lutz University of Chicago A variety of real time pulse analysis procedures, enumerated below, were loaded onto an FPGA for the purpose of extracting relevant information from the raw data generated in photo detectors. While referencing a few particulars as to how the analysis functions were actually instantiated in the form of VHDL code, this document describes in detail a number of simulations carried out on an FPGA after having been programmed with our code. Appendix provides the two raw test pulses used for simulations. Motivation It is computationally advantageous to perform various data analysis functions on the output signal from a photo detector in real time rather than channeling the raw signal to software to perform calculations after the device is finished taking data. Specifically, we would like to know the time of arrival of a given pulse as well as various features of the pulse waveform such as its average height, its full width at half maximum, its rising and falling times, the height of its peak(s), and the number of electrons it represents. Additional data related to the baseline (non pulse) signal such as its overall average, its standard deviation, and its significance is also useful for calibrating the actual pulse data. Approach and Implementation The real time computations will be carried out in an on board Field Programmable Gate Array (FPGA), which is fed pulse data in parallel from an ASIC acting as an oscilloscope for the actual photodetector. Programmable logic arrays in the FPGA can be manipulated in a number of different ways, and we have chosen to use VHDL code. We have assumed here that the input data will be passed from the ASIC directly to the FPGA without any mediation in the form of e.g. memory devices, etc. Output readings from the various analysis functions are also in parallel and, at least in the current conception of the code, last for a single clock cycle (the idea is that these quick readings can then be stored somewhere and read later). All output shown in these simulations come directly from the FPGA, an Altera Cyclone IV with serial number EP4CE22F17C6N which was programmed with the appropriate VHDL code using Quartus II software. Multi threshold timing analysis 1 P age Simulation of Timing Analyses Perhaps the simplest way to estimate the time of arrival of a pulse is just to record when it crosses certain pre determined threshold values. These values are highly dependent on the shape of the pulse, the desired accuracy, and the noise of the background signal, but for the purposes of simulation it suffices to use completely arbitrary thresholds and demonstrate that the program can accurately determine the times of the respective threshold crossings.

2 As shown in the simulation below using a Gaussian test pulse, the times of the three different threshold crossings are all output to a single set of 12 pins. This was done mainly for purposes of demonstration, and it would be easy to dedicatee three whollyy separate sets of 12 (or more) pins for each of the three crossing times: Fig. 1 : Times (µs) of respective threshold crossings on bottom, with Gaussian test pulse readout above for reference; thresholds at 7, 15, and 21 volts, respectively, pulse peaks at 79 volts The purpose of simulation is not, of course, only to see how the output looks but also to attempt to verify the accuracy of the output. But how are we to confirm the times in this case, given that we re working with microseconds? The brute force method would be, of course,, to rig some sort of third parthave all the timer to verify the times here, but it turns out that with a little cleverness we actually information we need in the above figure; we know that the test pulses are scheduled to repeat every 97µs, so if we compare the threshold crossings (of, say, the first threshold) for the two pulses shown above, we ought to find their difference to equal 97(!). The first pulse crosses the initial threshold at 1615 microseconds, and the second pulse attains the same value at 1712 microseconds. The difference here is 97 microseconds, exactly as expected. Just for kicks, let s see how well this timing discriminator holds up with a triangular waveform: Fig. 2 : Times (µs) of individual threshold crossings on bottom, with triangular test pulse readout above for reference; thresholds at 7, 10, and 12 volts, respectively, pulse peaks at 30 volts 2 Page

3 We find clean output and (as above) a 97µs periodicity as expected. Leading Edge Discriminator This proceduree consists of performing a linear fit on the three threshold crossing data points and then extrapolating to find where the regression line crosses zero; the time at which this occurs is then output. Though computationally expensive, this would actually be a relatively straightforward procedure were it not for the pesky truncationn that the hardware has too carry out. This major source of error was mitigated (though not eradicated) by multiplying relevant quantities by sufficiently large factors of ten before division takes place, and then dividing all of the tens out again in the final answer. Even though truncationn thus still occurs, the advantage of this method is that the truncation is saved for the final steps of the computation, rendering the intermediate computations more precise. And the extra work pays off: Fig. 3: Times (µs) of individual threshold crossings in the middle followed by the linear fit discriminator output time on the bottom, with triangular test pulse readoutt at top for reference; thresholds at 6, 9, and 12 volts, respectively, pulse peaks at 30 volts A close examination of the linear fit readout in the above simulation will reveal that in both of the above pulses the linear fit produces a time exactly 6 microseconds less than the initial threshold time. Is this what we re looking for? Remember we re working with a triangular pulse here, so the linear fit ought to be exact. And also remember that our first threshold is set to 6 volts, whichh a linear pulse with slope 1 should attain after 6µs. Thus a linear fit discriminator in Plato s perfect world of forms should give us readout of 6µs less than the readout associated with the first threshold. As fig. 3 demonstrates, Plato would be proud. 3 Page

4 Of course, this type of timing discriminator is not limited to triangular pulses; shown below is the same algorithm applied to a Gaussian input pulse: Fig. 4: Times (µs) of individual threshold crossings in the middle followed by the linear fit discriminator output time on the bottom, with Gaussian test pulse readout at top for reference; thresholds at 11, 14, and 17 volts, respectively, pulse peaks at 79 volts As a look at the actual test data shows (Appendix A), our thresholds are placed at a region where the Gaussian pulse first starts increasing rapidly; we thus expect the linear fit readout to afford a relatively modest improvement on the multi threshold method; in both pulses above, the lin fit readout is 3µs lesss than the time reported for the first threshold crossing. A careful inspection of fig. 4 also brings up another important point regarding the multi threshold method; we deliberately placed our thresholds close together (in reality, the three thresholds are breached one clock cycle after another, see Appendix A) to demonstrate what happens to the shapes of the three multi threshold time readouts. What wass initially a clean series of pulses is now sloppy mush owing to the fact that the outputs have no time to be shut up (as we ve programmed them to) beforee the next ones come in. This is a motivation to either ensure thatt the thresholds are carefully chosen to be sufficiently far apart (depending on the specificc shape of the expected pulses) or else to dedicate extra series of out pins to each of the three threshold discriminators to prevent this type of backup. The error is in no way fatal, but it could potentially lead to faulty outpu if not properly addressed. 4 Page

5 Constantt Fraction Discriminatorr In theory this is a measure of when the pulse reachess a constant fraction of its peak height, but in practice the computation is carried out by measuring whenn a version off the input pulse attenuated to 30% intersects a delayed version of the same pulse. No smoke and mirrors per se, but a lot of effort has to be put in to optimizing the specific parameters for the expected input pulses, whichh we have nott undertaken here. We will thus verify our simulation again by testing for 97 clock cycle periodicity: Fig. 4: Constant Fraction Discriminator output times (µs) on the bottom, with Gaussian test pulse readout at top for reference; thresholds at 11, 14, and 17 volts, respectively, pulse peaks at 79 volts The first readout converts to 703µs and the second too 800µs; 97µ µs periodicity as expected. Further simulations can (perhaps should) be undertaken and the parameters optimized, but fig. 4 suffices to show that we can at least expect no grossly aberrant outputs in such simulations. 5 Page

6 Elaboration and Simulation of Additional Data Analysis Procedures A: Baseline Analyses Baseline Averager Our artificial test pulses are unnaturally clean; in reality we expectt some amount of background noise and random jitters in the signal. In order to account forr this, it is useful to keep an average of non to account for long term trends, but a running average is another perfectly viable option: pulse signal data. In this implementation we consider a device for averaging the last 100 points in order Fig. 5: Baseline average on the bottom, with Gaussian test pulse readout at top for reference; thresholds at 35, 36, and 37 volts, respectively, pulse peaks at 79 volts, sampling last 100 data points We have artificially inflated the thresholds in this case in order to test the algorithm; as expected, we see that the average shuts up when the first threshold has been breached, and furthermore that the average itself is higher near the foothills of the pulse and lower in the seas of zeros that separate them. Restoring the threshold back to a more reasonable value and using triangular input data gives the following: 6 Page

7 Fig. 6: Baseline average on the bottom, with triangular test pulse readout at top for reference; thresholds at 7, 36, and 37 volts, respectively, pulse peaks at 30 volts, sampling last 100 data points Our sparklingly clean, hypoallergenic, and meticulously aseptic test pulses provide a wholly unsurprising baseline average of 0 (though to be fair, some of this is due to truncation) ). Baseline Standard Deviation Of all the processing algorithms implemented here, this is one of the most computationally cumbersome owing to the fact thatt a square root must be computed. After considering the sizes of numbers we will be expecting, we have created and optimized a continued fraction algorithm whose partial sums converge to the units place within 5 iterations assuming that the number the square root of which we are computing is less than (more iterations are necessary for larger numbers). Like the Baseline average, the standard deviation output shuts up once the pulse has breached the first threshold, and this triggers the running sum of difference of the signal from the baseline average to reset. It would, of course, be easy to tweak these specifications such that e.g. the standard deviation takes into account exactly the previous 100 dataa points or onn the other hand is a running figure, etc. A simulation using a Gaussian test pulse is shown below: 7 Page

8 Fig. 7: Standard Deviation on the bottom, with Gaussian test pulse readout at top for reference; thresholdss at 5, 36, and 37 volts, respectively, pulse peaks at 79 volts As expected, the standard deviation increases rapidlyy near the foothills of the pulse, while it levels out when it s being fed a constant stream of 0 s. We present as well a simulation using a triangular test pulse: Fig. 8: Standard Deviation on the bottom, with triangular testt pulse readout at top for reference; thresholdss at 5, 36, and 37 volts, respectively, pulse peaks at 30 volts 8 Page

9 Baseline Significance (forthcoming) 9 P age

10 B: Pulse Analyses Number of Electrons Since this calculation consists of nothing more than finding the integral of the pulse and dividing it by the charge of the electron, we will proceed directly to simulations of the integral calculator: Integral calculator/a average height We present these together because they are effectively the same process, save for the fact that the average height calculator divides the integral calculation by the elapsed time. By integral here we actually mean, of course, a simple sum of all of the data points between certain bounds in our algorithm specifically, the times of the initial and final armingg threshold crossings (which we ll label time1 and time2 respectively both in the code and for future reference). An illustrative simulation is shown below: Fig. 7 : Average pulse height (volts) readout on bottom, with pulse readout above for reference; triangularr test pulse with peak at 30 volts, arming threshold at 12 volts. In order to test this readout, we have tabulated the expected average value using an Excel spreadsheet; the total integral should come out to 768 volt*µ µsec, and the elapsed time is 37µs (note that time1 is when the pulse is greater than or equal to the arming threshold while time2 is when the pulse is first strictly less than the threshold again). Hence, expected: ; readout: 20 (16+4), which is accurate to within truncation error. Simulations were also carried out with a Gaussian test pulse, as illustrated below: 10 Pag e

11 Fig. 8: Average pulse height (volts) readout on bottom, with pulse readoutt above for reference; Gaussian test pulse with peak at 79 volts, arming threshold at 12 volts. Excel tells us to expect an integral of 1877 volts*µs and an elapsed time of 39 µs. dividing these two gives , or just 48 due to truncation precisely the same figure offered in the above simulation (48=32+16). Peak finder A simple algorithm comes to the rescue once again; once the calculation is triggered by a pulse value over the threshold, variable peak stores the highest value thus far, which is overwritten by any higher peak values. The peak time is stored for later use. As before, readout is issued at the threshold crossingg on the falling edge of the pulse: Fig. 9 :Peak pulse height (volts) readout on bottom, with pulse readout above for reference; Gaussian test pulse, with peak at 79 volts 11 Pag e

12 The FPGA gives us the anticipated 79 volt peak height. Since this peak finding algorithm is used in both the rising and falling time calculator and the full widthh at half maximum code, errors in this algorithm will impact the accuracy of these two other algorithms. Thus, instead of discussing other simulations of the isolated peak finder, we move on to these two more complicated calculations: Rising and falling times This calculation cannot be reliably done using only incoming pulse data; some kind of pulse memory must be implemented. Our code references the variables time1 and time2, which were recorded in the integral function above (and which specify the initial and falling edge threshold crossings, respectively), and then searches through the memory starting at the peak and then moves to the right and left in search of the two times (rising and falling) at which the pulse is first less than or equal to 90% of its peak value. The key trick here is the fact that, since the storage array pulsarsave is updated once per clock cycle, the relative position of data within the array gives us important timing information; thus (time2 time1) provides the total longevity of the pulse, and z provides the time when the pulse is 90% of its peak as measured by definition from time 2. This is enough too find the rising and falling times: Fig. 10: Falling time(in µs) readout on bottom, with Gaussiann test pulse readout above for reference; first (arming) threshold at 12 volts The pulse first drops below the arming threshold at 63 clock cycles (relative to the beginning of the pulse data), and our algorithm should detectt a 90% valuee at 48 relative clock cycles. The simulation above shows that the code indeed produces the expected value of 63 48= =15µs fall time (15= ). For purposes of comprehensiveness, we also include here a simulation of the rise time calculation, this time using a triangular pulse: 12 Pag e

13 Fig. 11: Rise time readout (in µs) directly from the FPGA on bottom, triangular pulse readout above for reference; test pulse peaks at 30 volts, arming threshold set to 8 volts We expect a rise time equal to the difference between the when the pulse reaches 8volts (the arming threshold) and 27 volts (90% of the peak of 30 volts). Looking at the input data, the desired differencee here is 31 12=19µs, which is what our simulation gives us (16+2+1=19). Full Width at Half Maximum (FWHM) The algorithm here is in essence identical to that given above for the rising and falling times; the memory is probed from right and left starting at the peak value until the stored pulse data is found to be half of the pulse maximum. The difference in the storage locations of these two data points is computed (since storage is updated once per clock cycle), giving the time between the two points and thus the full width at half maximum: Fig. 12: FWHM readout (in µs) directly from the FPGA on bottom, pulse readout above for reference; this simulation uses a strictly triangular test pulse with a peakk at 30 volts. 13 Pag e

14 We can quickly calculate the expected FWHM and then compare this to the above simulation in order to confirm the accuracy of our code; the triangular testt pulse is designed to peak at 30 volts, which means that the half maximum will be computed to be 15 volts. The test pulse is set to repeat itself every 97 µs, and, relative to this reset, 15 volts is reached at 19 andd 49 µs (see Appendix A); computing the differencee between these yields an expected FWHM of 30 µs, which is exactly what the above simulation gives us ( =30). An additional simulation using a Gaussian pulse is shown below: Fig. 13: FWHM readout (in µs) directly from the FPGA on bottom, pulse readout above for reference; this simulation uses a Gaussian test pulse with a peak at 79 volts. The code ought to pick up a half max value of 38 (given the test pulse see Appendix A), which occurs at 31 and 55 µs (relative to the pulse repeat). Expected FWHM: 24 µs. FPGA gives(drumroll): 16+8=24µ µs, as expected. 14 Pag e

15 Triangular pulse: Clock cycle Signal 0 : 0 1 : 0 2 : 0 3 : 0 4 : 0 5 : 1 6 : 2 7 : 3 8 : 4 9 : 5 10 : 6 11 : 7 12 : 8 13 : 9 14 : : : : : : : : : : : : : : : : : : : 28 Appendix A: Test pulse data 33 : : : : : : : : : : : : : : : : : : : : : : : 9 56 : 8 57 : 7 58 : 6 59 : 5 60 : 4 61 : 3 62 : 2 63 : 1 64 : 0 This is followed by 32 points of insignificant data (0 s), after which the pulse repeats starting at cycle 0 above. 15 P age

16 Gaussian: Clock cycle Signal 0 : 0 1 : 0 2 : 0 3 : 0 4 : 0 5 : 0 6 : 0 7 : 0 8 : 0 9 : 0 10 : 0 11 : 0 12 : 0 13 : 0 14 : 1 15 : 1 16 : 2 17 : 2 18 : 3 19 : 4 20 : 5 21 : 7 22 : 8 23 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 65 : 7 66 : 5 67 : 4 68 : 3 69 : 2 70 : 2 71 : 1 72 : 1 73 : 0 74 : 0 75 : 0 76 : 0 followed by 20 points of insignificant data (0 s), after which the pulse repeats starting at cycle 0 above. 16 P age