Wed., Mar. 28th

Juan is here and working on timing optimization.  He found this nice tool called Timing Optimization Advisor that made suggestions of ways to improve the timing performance.  It had a couple of suggestions which looked promising that we are trying.

To help out, I am going to make a list of all the settings I have fiddled with:

• Compilation Process Settings:
• Use smart compilation - I don't know if this affects performance at all; it supposedly can improve compilation speed, so I've been leaving it turned on.
• Incremental Compilation:
• Incremental compilation = Full incremental compilation.  I think this is necessary for partitions & LogicLock to be helpful.
• Physical Synthesis Optimizations:
• Optimize for performance (physical synthesis):
• Perform physical synthesis for combinational logic = ON
• Perform register retiming = ON
• Effort Level = Extra
• Fitter netlist optimizations:
• Perform register duplication = ON
• Analysis & Synthesis Settings:
• Optimization Technique = Speed
• Timing-Driven Synthesis = ON
• Fitter Settings:
• Fitter effort = Standard fit (highest effort)
• More Settings...:
• Placement effort multiplier = 4.0
• Router Timing Optimization Level = Maximum

At least, these are all the settings that I think were helping.

I'm also looking at possibly changing the state encoding for the pulse_cap FSM to a one-hot encoding (this was one of the things that the Timing Optimization Advisor suggested).  Not sure yet if this will help at all because that logic was, I think, pretty well-optimized already.

589.28 MHz - Baseline speed for high-speed datapath.

455.37 MHz - Speed after switching to the one-hot encoding.  Nope, it didn't help!

Continued working on server coding.  When I left off at the end of the day, I was about to write the code for the GPS_Manager that would cause it to watch for the condition where the TRAIM is not eliminating all satellites from the solution and is reporting a non-null accuracy value (and maybe also verify that the current time as reported by the GPS is consistent with the system clock), and in this case, it should inform the application's main entity (the CosmicIServer instance) that the GPS time is good, by calling its yo_GPS_time_is_good() method, which will then relay this information to the RunManager instance, causing the RunManager to proceed to the next step in its startup sequence, which has not been implemented yet (empty method bodies for now);  that step will be to start up the Timekeeper and then the DataCollector (both of which have also not been written yet) and then (next step) start the CTU - that last step should be really easy to implement though, since all the infrastructure for it is already there.  (We can go ahead soon and test this & the rest of the startup sequence, leaving empty method bodies in the routines to start up the Timekeeper and DataCollector temporarily.)