Mon., Jan. 23rd

David is here and I am going over the needed datapath changes with him.  I also uploaded the latest gelware files to the dropbox (FEDM_design\FEDM_code\q91).  Students, please note that the top-level filename and the revision name changed.

Also, copied several files in the firmware folder (software_v4) from Q:\ to dropbox, files for which the latest version was on Q:\:

• main.c
• dac_driver.c
• pulsebuf.c
• server.c

Just want to make sure the students are working with the latest version of all the files.  I also copied the new version of several files that I worked on at home over the weekend from Dropbox back to Q:\:

• interrupt_timing.c  (modified)
• tsdp_driver.c  (renamed & modified)
• tsdp_driver.h  (renamed & modified)
• timeval.h  (new file)

Now trying to find Juan & Michael's top-level file with the top-level wiring changes to support the new PIO (not sure they did one, but checking)...   It's not COSMICi_FEDM_top14, because Dropbox says there's only one version of that (the one I just copied in).  Aha, but with COSMICi_FEDM_top13, the previous version is dated 12/6, which is when Juan and Mike Dean were working on the firmware.  I'll restore that one.

Nope, the FEDM_NiosSys icon still doesn't show the new PIOs.  Let's go back to the newer version.

Let's now just try opening the SOPC System in their folder.  Hm, still don't see the new PIOs.  Maybe I overwrote their FEDM_NiosSys.sopc?  Nope, there's only one version of it in that folder.

Perhaps they didn't actually create the new PIOs yet?  Texted Juan & Darryl to ask them.  If they didn't do it, then I guess I will just go ahead and do it myself, to save time.  Should only take a minute.

Darryl says he doesn't think they were done yet.  Guess I'll do them myself.

Looking back at the pulseform-capture datapath for reference, in SOPC Builder, it looks like icdp_ctrl was 16 bits, with both input and output ports, and individual bit setting/clearing, and has output initialized to 0x5, which means:

• ICDP_RESET   = 1  (datapath initially held in reset state)
• RUN_PAUSEn = 0 (datapath operation initially not enabled)
• NEG_INPUT    = 1 (datapath will take negative input pulses)
• ICDP_SEL[1:0] = 0 (input channel #0 (SMA#1) selected initially)
• PUMP_DATA   = 0 (not reading out data from datapath)

Also, wrt its input, it synchronously captures rising edges, and allows bit-clearing for the edge-capture register, and generates an edge-sensitive IRQ.

Let's look back at the firmware to see how the control bits for the new datapath were defined.  In tsdp_driver.h, they are:

• TSDP_RESET    = bit 0 (output)
• TSDP_ENABLE   = bit 1 (output)
• TSDP_PUMPDATA = bit 2 (output)
• TSDP_HAVEDATA = bit 3 (input)
• TSDP_SYNCERR  = bit 4 (input)

The name of the control PIO is 'tsdp_ctrl'.  Clearly, an 8-bit PIO size will be sufficient for the time being.  The reset value should be 0x1 (TSDP_RESET=1, all others 0).

With regards to the data PIO, icdp_data is input-only, 32 bits.  tsdp_data can be the same.

OK, both of those are created.  Auto-assigned IRQs and base addresses.  Generating the SOPC system files now.  System generation successful.  Let's now try a Quartus compile, to make sure the design fits.  First I went ahead & wired up all the new I/Os (except for the pump-data input to the new time-sync datapath, which is still being driven by the test stub) to make sure that important stuff doesn't get compiled away.  OK, that's done.  Doing Quartus compile now.

Juan is having car problems and might not be in today.  Taking a break down in the break room to finish my lunch while the compile is brewing.

The Quartus compile succeeded; great.  Now we just need to finish up the gelware/firmware revisions.  Darryl, Michael Dean, & Aarmondas are all going to be here tomorrow, I believe.  David said he'd pass on the information I gave him earlier to Dean.

I'm puttering around a little in the firmware, cleaning up main.c a little.  And setting it up to initialize & start running the new datapath.

Tweaking server.c a little... server_tell_starting() now sends the message "HOST_STARTING,FEDM,v0.9". This is a generic message that could be sent by all nodes in the sensor network right after their Wi-Fi output is opened.  The second field identifies the node type (currently either "FEDM" or "CTU").  The third field identifies the firmware version ID.  Similarly, server_tell_ready() now sends "HOST_READY".  These changes are towards more uniformity with the CTU firmware (which can have similar behavior) to make it easier to write server code to properly track the identity and status of the remote hosts.