Tue., Mar. 20th

David is here.  Dr. O'Neal brought in his Windows 7 CD so David is using it to install Windows on the new hard drive for the Acer.  Unfortunately it wouldn't accept the license key (the CD is Professional, the license key is for Home), so we might have to tweak the installation later to downgrade it from Professional to Home, or something.  David is downloading a new ISO of W7 Home Premium (non-SP1) which he will burn onto a DVD-R.  We seem to be having a problem where this download keeps getting interrupted right at the end.

Darryl should be here later, and we can all talk a little about the paper if needed.  We were going to collect some new data to include in the figures in the paper, but it might be best to wait until we finish boosting the FEDM speed to 500 MHz so that the data we collect can come from the actual system (as opposed to a simplified mock-up).  An exception might be the figure showing an input PMT pulse next to the comparator outputs, since we don't actually need the high-speed clocks for that one.

Michael Dean is here.  He & the other Senior Design computer engineering students can work on making a single top-level entity for all of the high-speed components, which I think is the next logical step, since the lack of such an entity is the only reason I can think of why the speed of the high-speed stuff still isn't getting preserved when we add the other stuff - it's possible that, even though the individual high-speed instances are logic-locked, the routes between them aren't getting logic-locked currently.

Meanwhile, I could work on the FEDM model/proxy code, which has barely been started so far.  Basically I first just need to add the handlers for the various FEDM-specific messages.

What to load onto the FEDM for testing?  Looks like all my compiles from yesterday had the PLL speed set to 250 MHz.  I should be able to turn it up to at least 300 MHz based on the last Fmax from yesterday.  What if I compile with PLL=500 MHz, does that affect Fmax at all?  Let's try it...

Fast stuff only:    552.49 MHz.
Add slow stuff:   307.22 MHz.  Boo.

On the FEDM model coding:  Currently, we need to add support for these 3 message types:

• NC_PULSES - 6 arguments
• FIFO_FULL - 4 arguments
• CON_PULSE - 7 arguments (last one has nested commas in parens)

Modified fedm.py to dispatch these 3 methods to (currently still empty) handlers, so that at least we won't get error messages for them.  David tested COSMICi_server.py to make sure it runs on Windows 7 - it does (at least up to the starting screen).

Meanwhile, Trying another compile on laptop.  That one had the pipeline registers.  Tried merging partitions after LogicLocking; that caused the multi-hier partition to get a LogicLock icon.  Maybe that will help.

Fast only:  564.33 MHz.

Add slow:  335.23 MHz.  (I think this is the best yet with the full system in there?)

The placement effort level on the laptop wasn't turned up all the way.  Fixed that; redoing.  Meanwhile, another compile on PC, with pipeline registers and entire merged partition in LogicLock:

Fast only:   582.07 MHz.
Add slow:  266.24 MHz

What did I do wrong?  Failed to recompile Top from source?  No, that only got us to 266.81 MHz.  Hm.  Not sure why results are so different between PC & laptop compiles right now.  Some minor settings difference?

Laptop:

Fast only:   596.66 MHz  (Is this about the best so far for just the high-speed components?)
Add slow:  345.9 MHz  (Is this the best so far with the full system?)

Now on laptop got 346.48 MHz for the whole system.  Can we hit 350 MHz?  We're so close!  No, blah, this time I only got 321.96 MHz!  Yuck!

Trying compile on desktop with less-aggressive settings for the top partition.  Maybe this will help now that the multi-hier is logic-locked?  No, blah.  Made desktop settings same as laptop.  Now getting 338.98 MHz.  At least it's over 300.