Tue., Nov. 8th

Ray and I are planning to go over to CLC at about 4 pm on Wednesday to talk with Reed about positioning of the detectors.  I created a Google Calendar event and sent them both an invite.

Ray points out that the highest-energy showers have a narrower area at ground level, so placing the detectors as far apart within the building as possible might not be the best approach.  He is going to ask Helio to help us find information about how the shower area varies as a function of primary particle energy.

Some things I could work on today:

• [/] Requisition for Tektronix BNC cables - submitted
• [,] Shrink existing design to make room for timing sync capture datapath (reduce code size, use more of M-RAM)
• [ ] Solder headers to 2nd Wi-Fi board, wire up its serial connection
• [ ] Reduce startup time of WiFi script / Increase startup delay of FEDM

I guess the quickest way to get the startup sequence working is just to add a delay to the FEDM firmware - we can always go back and optimize things later to reduce the delays on both sides (WiFi & FEDM).

Added a 20-second startup delay to the firmware in Q:\software_v4\FEDM_ctrl_fw; this firmware version is 0.9.

Incidentally, the linker space usage summary is as follows:

Info: (FEDM_ctrl_fw.elf) 69 KBytes program size (code + initialized data).
Info:                    62 KBytes free for stack + heap.

This might be a good time to try shrinking the code size.  Let's compile with space optimization.  In Nios II Design Tools for Eclipse, right-click fedm_ctrl_fw_bsp, select Nios II --> BSP Editor.  No, that's not it.  Select Properties instead from the pop-up menu.  Click "Nios II BSP Properties".  Select optimization level: Size.  Hit OK.  Select Nios II --> Generate BSP.  Select Project --> Build All.  Hm, that didn't seem to work - not enough files were recompiled.  Let's click "Generate" in BSP editor, and rebuild.  Still nothing.  Let's do a Project -> Clean, and clean all projects.  That'll force the issue.  OK, that does it - all files are getting recompiled with -Os.  Now we get in the linker summary:

Info: (FEDM_ctrl_fw.elf) 68 KBytes program size (code + initialized data).
Info:                    62 KBytes free for stack + heap.

Geez, we only saved 1 KB?  That's hardly worth it.  I think I'll change it back to the way it was.  (-O3 not -Os).  OK, that's changed back.

Next thing to try:  See if we can utilize the extra 8K of M-RAM (parity bits, not presently used).  Opening Q:\COSMICi_FEDM project, New_with_Nios_trim revision, SOPC builder.  Changing size of working_memory module from 64K to 72K.  This might let us get rid of extra_RAM.  System generation worked.   Extra_RAM is currently 9KB, and it uses M512 blocks, so getting rid of it might free up some space for other functionality.

OK, I went into the BSP editor, linker script tab, and changed the size of the working_memory linker region to 73,728 bytes (72 KB), and regenerated the BSP files.  After rebuilding, new linker stats are as follows:

Info: (FEDM_ctrl_fw.elf) 69 KBytes program size (code + initialized data).
Info:                    70 KBytes free for stack + heap.
So that worked as intended; we have an extra 8 KB now available in the stack + heap working memory.
So, the stuff that's currently going in extra_RAM could be shoved into there, maybe - except the problem with the M-RAM is that it can't be initialized!  So I'm not sure it really can be used for anything but stack & heap, unless we somehow work around the no-initialization restriction.  I guess .BSS sections can go in there too, but that's about it.  Damn, I just checked the linker script settings, and .BSS is already in there!

Darn, when I tried the Quartus compile, the fitter says it needs another M-RAM!  Maybe it can't allocate the extra 8K of parity bits as normal memory?  Let's see if it helps to change the word size to 16 bits (from 32 bits).  Nope, still no dice.  Sounds like I am going to have to stick with using 64KB of M-RAM, unless we find some other way to use the rest of it.  Also, when we try to generate with smaller word sizes, we get the following scary warning:

Warning: cpu_0.data_master/working_memory.s1: working_memory.s1 does not have byteenables. Narrow (less than 32-bit) writes from cpu_0.data_master will result in spurious writes to working_memory.s1

In other news, Juan and Michael Dean were here today, and I had them start work with Darryl & David on the new datapath for the timing sync capture.  Juan & Darryl are working on the new PIOs and the firmware changes, while Michael & David are working on the Quartus changes.  I copied the latest code (gelware & firmware) to the FEDM_design\FEDM_code\q91 folder so they could be working with the latest versions of everything.  Everyone got off to a good start today, but there is a lot left to do.  Juan & Darryl will give specs to Michael & David as to the PIO interface.

Aarmondas did not show up as promised.  Going to send him a strongly worded e-mail.

Also, Ray finished his data collection run that he started last night, in which the scintillators were overlapping at their centers.  It didn't change the location of the histogram peak much, for coincidence pulses due to showers propagating down through both detectors, so we are still thinking that 200 mV is the right level for the thresholds.

Speaking of which, currently the furthest threshold (DAC #6) is -1000 mV (off of a +2.5V DC bias) or in other words +1.5V absolute.  Thus, DAC #6 would be appropriate to use as the rising-edge threshold for the timing-sync input, since that pulse is going to be at (I believe, if I recall) the +3.3V logic level of the DE3 board.