Monday, August 29, 2011

Mad Scramble

We're scrambling like mad to try to get some good data, especially since Ray's NSF report is due in two days.  It would be nice to have something for it.

Input channel 2 is still being flaky.  Sometimes it sorta works, but with garbled data values.  Other times it generates an enormous bolus of pulses that are all too wide and then crashes the firmware.

I wonder if the latter is maybe because drops of water are dripping onto the board from the thermoelectric cooling plate.  This is why we need a proper cooling system designed for this board!

I changed the program to tell the initial DAC levels to the server, so at least that critical information will be included in the data logs.

Tried increasing the system clock speed to 80 MHz, in hopes that the hardware FIFO on channel 2 won't fill up as often.  Then I realized this is really not a very good idea, because it messes up the DAC controller, which has to go slow enough for the DAC chips to keep up with.  But, I can fix that by clocking the DAC controller module directly off of the 50 MHz external clock.  It should still be able to be controlled by the dac_cpu_if (running at 80 MHz) because the protocol used between those two modules is asynchronous.  First the 72-bit (6x12) parallel data bus is configured, then (a bit later) the dac_go signal is raised.  Once it sees this signal go high, dac_control then reads its input bus and takes care of all the rest on its own accord.  Due to the delay between setting the data bus and the go signal, there should be no setup time issues.

At some point, I also need to revisit the performance issue for the high-speed parts of the input capture system.

During the most recent round of debugging (after adding the 2nd datapath), I had to lower the high-speed clock from 500 MHz to 200 MHz to avoid violating timing constraints and get both datapaths working reliably. Sometime, we need to figure out how we can crank the speed back up.  One approach:  Compile the high-speed components in isolation, and then put them into a LogicLock region to prevent them from being relocated in subsequent compiles.

At some point I also need to figure out why the firmware is crashing sometimes.  I could do a run under the debugger, and then suspend execution when I get into a hung state and see where we are in the code.  I suspect it is the STDIO libraries again, but don't know why they're having problems.  Memory issues still?

I added some macros to let me stub out the DEBUG() messages and other diagnostics to save memory when I am not otherwise using them.  Basically, in debug.c you now just set MIN_REPLEVEL to the level of the lowest-level diagnostics that you wish to be able to see, dynamically.  Any diagnostics below that level will be compiled away.

OK, switching DAC_control back to 50 MHz fixed the DAC levels, at least.  But now I'm getting no output!  Argh.  And now, I'm getting output but the CPU is restarting every 10-15 seconds.  But I can prevent it from restarting by pausing the high-speed time counter!  Weird.  Mebbe I need to start using a Gray counter or something, for reduced noise?  Great, a carry-save Gray counter, I don't have that yet!  Does it even make sense?

I'm going to back out of the increase of the system clock speed to 80 MHz, as it seems to have only made things worse (although, between the restarts just now, the system was working fine)!

Actually, maybe it was just overheating, b/c I added the cooler back on and now it seems to be working again without resetting itself...

And now, it's *not* working...  I'm so confused!  I think I need to go more slowly and take more careful and detailed notes about every single little thing I am doing.

OK, what's happening right at the moment is, I'm recompiling the Quartus design with the original clocks again, but with the timer_0 device simplified to a basic periodic timer (since I wasn't using its advanced features anyway).

Oh of course, fatal error in Quartus.  Everything is going wrong today!  Not to mention that FAMU's Internet connection was down for an hour in the middle of the afternoon.


No comments:

Post a Comment