CHECK OUT OUR NEW BLOG!

Please check out our new blog FPGASiena2017

  https://fpgasiena2017.blogspot.com.

Is your Virtual Machine Running Slowly?

If your virtual machine is running slowly it may need to be defragmented.
Follow these steps and use the link at the bottom of the page for detailed pictures.


Launch VMware player
Highlight the virtual machine that you want to defragment
Player >  manage  > Virtual machine settings > Highlight Hard Disk > Defragment > ok


Your virtual machine should be working more efficiently now!






http://www.tomshardware.com/faq/id-1860617/vmware-virtual-machine-runs-slow.html

Recreating the sum_io

The first step is to launch vivado HLS (2016).

* Helpful Blog Post For Review: Things We Should All Know About Vivado HLS

Create a new project > name the project > Choose a location > Next

Add Files: Here you want to add the file sum_io.c you may need to download this from Mike's files if it is not already saved.
Top Function: sum_io > Next

Add Testbench Files > sum_io.test.c > Next

Solution Configuration:
Solution Name > Solution1
Part Selection > Zedboard > Finish

Project Tab > Run C Simulation

Under Source > Select sum_io.c > Directives Tab > Right Click sum_io > Insert Directive >  Interface > ap_ctrl_none

Run C Simulation

Solution > Run C Synthesis

Solution > Export RTL > Options:VHDL > OK

Now you are ready to launch Vivado (2016)

*Helpful Blog Post Fore Review: Things We Should All Know Vivado

New Project > name the project  > Choose Location > Next

Choose Zedboard Rev C > Next > Finish

Create New Block Design > Name it

Right Click > Add IP > ZYNQ7 Processing System > Run Block Automation

Now we need to add seven GPIOs:

Rt. Click > add IP > AXI GPIO > Run Connection Automation > ✓GPIO > LEDs > Run Connection Automation

Next, insert 3 AXI GPIOs, an Adder/Subtracter and a Constant.

Double click one GPIO1 > IP Configuration > ✓All Outputs > GPIO Width 15 > GPIO Width 32 >
ok

Double click one GPIO2 > IP Configuration > ✓All Outputs > GPIO Width 15 > GPIO Width 32 > ok
Double click one GPIO3 > IP Configuration > ✓All Inputs > GPIO Width 16 > GPIO Width 32 > ok
Double click one AddSub > Basic Tab > Input Width 15 > Output Width 16 > ok

Connect the output of gpio1 to the first input (A) on the add/Sub  and connect the output from gpio2 to the second input (B) on the add/sub. Next connect the output of the adder/sub to the input of gpio3. Finally connect the constant to the bottom input of the add/sub (CE). Now Run Connection Automation. Your block diagram should look like the bottom right corner of the picture below.

Next add three more AXI GPIOs.

Double click one GPIO4 > IP Configuration > ✓All Outputs > GPIO Width 16 > GPIO Width 32 > ok
Double click one GPIO5 > IP Configuration > ✓All Outputs > GPIO Width 16 > GPIO Width 32 > ok
Double click one GPIO6 > IP Configuration > ✓All Inputs > GPIO Width 32 > GPIO Width 32 > ok

Now we need to insert the HLS Repository that we made in the first step.

Project Settings > IP (on left) > Repository Manager > + > Select the path where you saved your HLS file (Ex. Sams_FPGA_projects/Sam_Sum_io/soln1/impl/ip) > Apply  > ok

Right Click > Add IP > sum_io

Now you want to connect the output of gpio4 to the top input of the sum_io and the output of gpio5 to the bottom input. Next connect the output of the sum_io to gpio6.
Run Connection Automation and your block design should be complete.

Now you can save and validate your design. 

Tools > Validate Design

Switch to the sources tab by selecting window > sources. Right click on the top level system > Create HDL Wrapper

Flow Navigator > Generate Bitstream > Open Implemented Design > ok

File > Export > Export Hardware > ✓ Include Bitstream 

File > Launch SDK > ok

Create a new empty application

Expand sumIO > Right Click on src > import > AddComp.c

Now you can program the FPGA. Once the FPGA board is programed

Right click on sumIO > Run As > Launch On Hardware

NOTE: I found that it was useful to run the code using GTKterm. I was unable to get it to work anywhere else.

Your code takes two values and adds them together. The sums are what should be printed out in the terminal. You should get one that says Xilinz Output Adder = 2 and HLS Output Adder = 4. You can change these output values by changing the input values in the code.

Inserting Directives Video Tutorials

Specifying AXI4 Interfaces for your Vivado HLS Design:

https://www.youtube.com/watch?v=URUVkq6zQhQ

Writing SDK code to talk to HLS ip.
http://www.xilinx.com/support/documentation/application_notes/xapp745-processor-control-vhls.pdf

Understanding C pointers:
https://www.youtube.com/watch?v=TFTpRjPcoUs

HLS adder:
http://home.mit.bme.hu/~szanto/education/vimima15/heterogen_xilinx_hls.pdf

Access HLS IP in SDK, pages: 232-263:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_2/ug871-vivado-high-level-synthesis-tutorial.pdf

Data from NASA Lab -- Other Updates

The plot I have attached shows gamma induced events from three sources of radiation (Co-60, Cs-137, and Co-57). 

The distributions of the data contain a lot of noise (on the left side of the plot), because of the trigger level on the oscilloscope. I kept the trigger level at 10mv (any higher and I would lose valuable data) to get a good distribution of points. You'll notice that with the Co-60, everything up until about 0.04 V is noise (and there is a lot of it) and the gamma events are located on the interval between ~0.45 and 0.07 V.

For the other two sources, the idea is the same, it is just more difficult to distinguish the noise from gamma events, because the the signal produced by the gammas (multiplied by the SiPM) is much closer to the noise for Co-57 and Cs-137 than it is for Co-60. To get an idea about how much the original energy is amplified by the photo-multiplier, we can look at the Cs-137. If you look up the gamma energy associated with a radiating Cs-137 nucleus, you'll find it to be ~660 keV. And the peak voltage found in the experiment (see green Gaussian) is ~0.03 V. 

The phenomenon shows itself even more so with the Co-57, as the distribution just appears to be one smooth exponential falloff with an increase in pulse height. But, if you look closely, you'll see a second peak just to the right of the noise peak channel (red Gaussian) that represents the gamma induced events. I am convinced of this, because if I try to run the experiment with no source or a very weak one (Am-241 (~60 keV) for example), I am left with a very noisy distribution, which is to be expected. Basically, I don't see the second peak where the Co-57 has another peak.

When I first took a look at this plot from some of Georgia de Nolfo's work I was confused in thinking that the plot was just of the peak heights from one event (one csv). But upon further inspection I learned that it is a plot of a certain number of events (5-,000-10,000) and the associated peaks calculated from the PSD algorithm we are familiar with. With a better understanding of the plot, I could recreate the experiment and use the algorithm I wrote to get the peaks.

It is important to understand the gamma induced event and why we get a pulse. When a gamma ray collides with an electron inside our p-terphenyl, inelastic scattering called Compton scattering occurs. The scattered photon from this reaction will have an energy that is some fraction of the incident energy while the remaining kinetic energy is transferred to the electron. The Compton edge is the maximum possible energy deposited in the detector (electron) occurring at 180 degrees. The range of energies deposited can be determined by the scattering angle of the resulting photon. Looking at the plot below for a 500 keV photon, we can see that the maximum energy deposited in the detector is ~320 keV. 

Once the secondary photon is scattered with some fraction of the incident energy it is detected by the SiPM array. This is where the photoelectric effect takes hold. Because the energy of the gamma ray is less than the initial energy, the effect shifts from Compton to photoelectric inside the photo-multiplier. An electron is ejected from the material and multiplied inside the SiPM (keep in mind that this is a diagram of a PMT which works a little differently than the SiPM):

Other than doing the FPGA stuff with Joe, and working with the hardware in the lab, I have been tasked with comparing both the peak height and pulse shape from two competing algorithms (version 1 and version 2). Since Georgia originally sent the python code to us last summer, the code has made significant advancements in precision. An engineer named Jeff Dumonthier (who wrote the first version as well) updated it and took me through the main differences:

1. The time of flight is the difference in the beginning of the pulse in the double scatter experiment I described in the other blog. The time of flight for these events is on the order of ~1ns. So precise calculation is needed to determine the exact instant of the CFD time-- the constant fraction discriminator time. Remember that the CFD was calculated as the value that is 25% of the peak voltage. If we can accurately find the time value that the pulse is at 25% of its peak value for both detectors, we can do a simple subtraction and see how long it took a gamma ray/neutron to cause an event in both. The way the DRS is set up, it only saves an event if both detectors are triggered. So the XML file we receive has 1024 time/voltage pairs (as opposed to the 502 pairs from the LeCroy scope) for detector 1, followed directly by the same number of pairs for detector 2. It is important to note that this 25% value is arbitrarily selected and needs (probably) to be optimized to produce the best version of our ToF measurement. The following plot shows the time of flight for a set of 1,000 events. You'll notice two distributions on the plot, the small one corresponding to neutron induced events, and the other to gammas. In this plot the subtraction is reversed between detector 1 and 2, so we can conclude that the neutrons have a longer ToF than gammas (as expected because of their greater weight and lower velocity) and gamma events are more probable than neutrons over the data collection interval. 

2. Because time is so important now, everything in the new algorithm is calculated through the time vector. So, instead of just calculating which bin (0 to 502) the pulse height and pulse CFD are at, the new code finds both the closest time bin (real value gotten from the DRS) and the actual time value of both values. Realizing that this is sort of confusing I will describe more here:
1. For one event in one detector, we have 1024 time/voltage pairs. With the LeCroy we had 502 time/voltage pairs. We simply marched up the leading edge of the pulse finding the index of the time/voltage value closest to 25% of the peak. We then chose a precise number of bins coming after that index to calculate both the long and short interval. The algorithm has been updated to instead of simply finding the closest value to the CFD time, it finds the exact time of 25% of the peak by fitting a line to the leading edge. Because part of the leading edge of each pulse is 'very linear' we can take some upper and lower range of the edge (say 15% to 50% of the peak) and save all the time/voltage pairs into a matrix. From there we calculate a slope and intercept. Knowing the exact 25% voltage of the peak we can subsequently calculate the exact 25% CFD time threshold. Then we can get ToF!
   
2. Using the 'binning method of inexactness' I was getting a ToF distribution that had a similar shape to the one as above, but the measurements were scattered over a greater range of ToF channels. If you look at the largest number of counts for the ToF above you'll see ~170 events at the peak. With the bins the largest number of counts in the peak bin was ~35 events (withe the same 1,000 event set). 
3. The overall goal of comparing the old and new versions (and not just going with the later version) is to find a 'lightweight' enough algorithm that produces precise enough results and can be implemented on an FPGA, aka written in such a way it could be written in HDL (or synthesized by HLS for us). The way things are calculated for each algorithm is as follows:
1. Version 1 Agorithm:
1. Pre-Filter:
1. Subtracts out first time element from time vector to normalize/zero-out set
2. Inverts voltage polarity (LeCroy gives negative vals, DRS gived positive vals)
2. Pass 1:
1. Baseline - finds average of constant number of voltage points preceding the leading the edge of the pulse and uses that as a zero such that postY=MAV-baseline.
2. Performs smoothing function (moving average filter) and finds 4 greatest values of post-smoothing array. Finds average of those four to find pulse height/index.
3. Pass 2: 
1. Finds CFD as closest time/voltage value to fraction of the peak.
2. Performs integration over two regions a fixed distance -- number of bins -- from the CFD index. 
3. Divides the Long/Short interval to give Pulse Shape.
2. Version 2 Algorithm:
1. Pre-Process:
1. Subtracts out first time element from time vector to normalize/zero-out set
2. Base and Scale
1. Baseline - uses all voltage points before a certain time value and computes average.
2. Subtracts baseline from all voltage values (no smoothing first)
3. Peak
1. Fits a parabola to a fixed number of points in a range of points near the max of the pulse. Takes max of parabola to find height.
4. Leading Edge CFD
1. Finds CFD time/voltage by fitting a line to range of voltage values along leading edge
5. PSD
1. Takes time/voltage pair closest to CFD time threshold and performs integration over two regions of a fixed time.
4. After running through the comparisons of each algorithm for the baseline voltage, peak, cfd time, and psd calculation I found that Version 1 does a good job of finding the baseline and calculating the peak using smoothing but does not do a very good job of finding the CFD time and finding the ToF. So I adjusted the CFD calculation to manually fit a line between two points, because something like polyfit in python would be too cumbersome to replicate in the FPGA. Here are the comparisons between Version 1 (Mike) and Version 2 (Jeff) for finding the peak and CFD time:
   A typical baseline voltage is -.0022 V. So the difference being ~0.0001 is not large enough to say the binning baseline calculation is useless. Version 1 matches Version 2 pretty closely.

A typical peak voltage is 0.03-0.06 V. So the difference being ~0.0001-0.0002 is not large enough to say the method of smoothing is useless. Version 1 matches Version 2 pretty closely.

Because in both algorithms the CFD voltage is calculated as a certain percentage of the peak, the difference in CFD voltage will be the same as it was for the difference in peak voltage (just a scalar modification).

A typical CFD value is 5.5e-07 so the difference for CFD time for Version 1 and 2 being 2 orders of magnitude smaller shows:  The method of finding a point directly above and below the smoothed curve CFD voltage and fitting a line between those points (to find the CFD time) does as good a job as an un-smoothed range of points 15-60% of the peak with a line fitting those points to find the CFD time. Also now Version 1 has an easier transition to C or HDL.

Instructions to replace the Analog Devices BOOT.BIN with your own

https://docs.google.com/document/d/17Dk7LKYh8bDYon4smHx6lIRhLAoP3ppRFI5bbZ-NWFQ/pub

Lab Setup

• LeCroy WaveRunner 2Ghz Oscilloscope: Expensive scope that allows you to insert a USB stick and collect events when the trigger level is met. The data is saved into CSV files and can be processed from a directory. 

• (Left): Light tight box that allows you to isolate gamma, alpha, beta radiation without disruption from outside light. Cables coming from the box include output cable (to the scope), power cable connected to 27V power supply (potential needed for SiPMs), and 3.3V-5 V cable needed to power the board that the SiPMs are installed on.

• SiPM array (silicon photo-multiplier). The scintillator crystal is placed atop the array with a radiation source placed directly above that. The whole experiment is then placed in a light-tight box (pictured above). There are two types of SiPMs we are currently testing; the SensL SiPMs requiring 27 V potential and the Hammamatsu SiPMs requiring 54 V potential. The trade-off is that in flight, the SensL's will consume less power but will produce more noise than the Hammamtsu's. They are arranged in an array because the experiment is set up to be a double scatter where the angle of the incident radiation can be determined. 

• Example of how the double-scatter experiment can be set up. Changing the alignment of the detectors, and the position of the source changes the data we see. 

•  The second option for digitizing data. The DRS4 chip with evaluation board being fed into the laptop in the background. Data is saved in XML format and can be saved on a USB drive as well.

• Double scatter instrument connected to DRS.

• The big picture, my lab setup.