Thu., Feb. 23rd

COSMICi advising mtg @ 9:30 - Had the meeting.  Everyone was there but Brian; but he showed up right after the meeting, and says he will be there for future meetings.  It sounds like the team will be in relatively good shape for their review next Wed. @ 3:30, although the ME guys still need to finish some fabrication work before then.  Brian can't make it to the review, so he is going to take his part (the enclosure) around to the evaluators ahead of time on Tuesday so they can see it, and then bring it to lab so it will be there during the main review on Wednesday.  No word yet from EIT on opening ports for off-campus access to license server.  [ ] Ping them on this again later.


Stopped by lab around 2 pm to let Mike Dean & Darryl in to do some work on the LogicLock, started license server for them, then had to go back over to Engineering for a meeting there.  Returned a little after 4:30 about the time MD was leaving; he said the entire input-capture system didn't fit in the LogicLock region.  No big surprise, I suppose.  Oh well, we didn't need the whole thing to be in there anyway.


Met with Samad to go over his power-distribution board design.  There were a couple of issues with his capacitors, and I also suggested he might want to group the outputs by destination board rather than by voltage; this will help the wire bundles look neater.  He is going to redesign it and we'll go over it again next week; hopefully it will soon be about ready to fabricate.  Donte can make this one in-house.


Worked with Darryl for a bit as he tried LogicLock on the pulse_cap module by itself.  (That is the one that captures the rising and falling edge times for a single digital pulse.)  At first he had a problem with too many output pins but we fixed that by routing the outputs to a new VHDL module that just applied a KEEP attribute to all its inputs.  Then he found it was limiting the input clock frequency for 500 MHz but that was just an I/O pin limitation which was fixed by generating the clock using a PLL.  Then he got something like 900 MHz.  Since both the high-speed counter and pulse-cap can run at well above 500 MHz by themselves, this suggests to me that our current speed issue might just be due to the fan-out of the counter value.  Currently it fans out to 18 instances of pulse_cap.  This can be reduced to 15 since we are only using 5 of the 6 DACs at present.  However, it is still a significant fan-out.  A combinational buffer or a pipeline register at the counter input to each datapath would reduce the maximum fan-out from 15 to 5.  Of these two, the pipeline register would perform better since the combinational delay of 3+5=8 fanout-delay units for the buffer is greater than the max 5 fanout-delay units we'd get in the pipelined approach.  Anyway, we should experiment with this approach tomorrow.  It's possible that, if this is really the underlying cause of the speed problem, adding the buffering might fix it without our even having to use LogicLock regions.  However, even in this case, having experimented with LogicLock will still have been helpful in terms of letting us track down the cause of the problem.  I also think that it still might be a good idea to move the high-speed components into a LogicLock region anyway, simply because Quartus seems to do a better job of optimization within those regions.  If we get the design just right, and eliminate the present speed bottlenecks, recent experiments suggest that in the final design, we might be able to achieve speeds well over 500 MHz, perhaps around 800 MHz.  Or, we could try again with the dual-edge-triggered version of the high-speed stuff and perhaps even hit 1 GHz.  Anyway, the possibilities look promising.


Antony is going to stop by on Friday (tomorrow) afternoon to get some soldering advice and back up COSMICi's hard drive.

Another thing I want to do tomorrow (besides help as needed with LogicLock stuff) is test my current server code for initializing the GPS module.  So far we just do a warm-start.  See if that works.