Wed., Nov. 16th

Michael Dean came by my office yesterday and I answered some of his questions on the timing system.

Accidentally turned in the wrong timesheet yesterday (for the wrong pay period), so had to spend some time today running around getting the correct one (don't know why I didn't already have it), filling it out, getting it signed & turning it in.  The system for getting paid is so inefficient!

Today I want to try compiling with different versions of the Nios core and see how much space it saves.

As a baseline, the present design (with the Nios II/f) is as follows:

• Entire design (COSMICi_FEDM_top12):
• Comb. ALUTs:  10,017 / 27,104 (37%)
• Ded. log. regs.:   25,678 / 27,104 (95%)
• M512s:                   188 / 202       (93%)
• M4Ks:                    144 / 144       (100%)
• M-RAMs:                   1 / 1           (100%)
  
• SOPC system (FEDM_NiosSys):
• Comb. ALUTs:   2,324  (8.6%)
• Ded. log. regs.:    1,901  (7%)
• M512s:                  150  (74%)
• M4Ks:                   144  (100%)
• M-RAMs:                  1  (100%)
  
• Nios CPU (the_cpu_0):
• Comb. ALUTs:   1,396  (5%)
• Ded. log. regs.:    1,486  (5%)
• M512s:                      4  (2%)
• M4Ks:                     16  (11%)
• M-RAMs:                  0  (0%)

So at best, by changing the CPU to a much smaller one, we could bump up the available logic registers a bit (less than double), increase the available M512s from 14 to (at most!) 18, and increase the available M4Ks from 0 to (at most!) 16 (11% of the total number).  So it's not a huge difference, but it does potentially make some difference.  Need to keep this in mind if we run out of space again (or if we need to loosen things up for improved performance).  Later on, we can do some test compiles to see exactly how much space we can safe by moving to the Nios II/s or e.  (Note: It could however increase firmware size, due to the need for software multiply/divide instructions.  It could also reduce performance and lead to more dropped pulses.)

I had a thought earlier in the day, which is that we could add a PLL in the GPS app, to more precisely measure the PPS edge times relative to the OCXO clock.  The OCXO clock is 10 MHz, but it would be pretty easy now (given the code already written for the FEDM) to step this up to a much faster speed.  50 MHz?  100 MHz?  500 MHz?  It would be fun to try.

Samad came by and we tried to solder the other 40-pin DIP header onto the other Wi-Fi board (#3), but had some problems, due to my hand shakiness; solder got stuck in some thru-holes, blocking them.  I tried several methods for removal, but no luck yet.  We may need to try again with another board.  Or, if I can find a small enough drill bit, we could re-drill the holes.  (I looked through all my Dremel tool attachments, but didn't find anything suitable.)

Finally managed to work the solder out of the holes by hand using a tiny eyeglass screwdriver, then soldered the second breakaway header strip of 20 pins.  After all the work with the solder tools there is a lot of charring of the board surface.  I cleaned the board as best I could with the electronics cleaner spray, then rinsed in water, shook the drops off, and placed it to try overnight on the exhaust vent of the soldering fan.  Test tomorrow to make sure it's working OK.

Not sure there's anything else I can really do at the moment.  Tomorrow I will test connectivity on Wi-Fi board #3 between pins of J2 (with the new header) and corresponding thru-holes of J9.  Once that's working, I will do a new serial connection between Wi-Fi board #3 and the DE3 board's GPIO1 header using a bundle of Adafruit jumper wires, like I did for the FEDM.  Then I'll test that Wi-Fi connection by running the existing GPS app.

Spent a little time playing around with using some of the Adafruit extra-long M-M pin headers and F-F jumper wires to supply the +3.3V, +5V, and +12V power on a small breadboard.  The quality of the power supply connection is poor though - it keeps going out, and you have to hold it in just the right way to maintain steady power.  So, getting the right connector from Digi-Key for mounting on a real proto board will be key here.

Temporary hand-made connector/wire bundle for distributing power supply voltages on breadboard.
Color code: Black/white = ground; Orange/gray = +3.3V; Green = /ON; Red = +5V; Yellow = +12V.

I am a little concerned about distributing +5V power (which will account for the biggest part of power consumption, I'm guessing roughly 4A = 20W worth, since it will drive the FEDM, both Wi-Fi boards, the GPS module, and the fan) via the relatively narrow-gauge jumper wire shown here.  This could potentially represent a fire hazard if this wire overheats.  It would be safer to use a slightly thicker-gauge wire such as the one used in the actual power-supply connector.  Alternatively, we could do an analysis to show that there is no hazard even with this narrow wire.