June Bug

I found a used car I think I might buy, if I can get the financing approved... I will broach that subject with the dealer tomorrow.

It's a little difficult to concentrate on work right now, what with my worries about my transportation, summer finances, and Fall employment. Still no word on my pending job inquiry. The guy I am supposed to talk to was not there again today... (Turns out he is out shopping around for a minivan, just like me!)

I posted a "seeking work" Tweet with a link to my CV... Perhaps, I will try some freelancing site, elance or odesk or some such.

ACTUAL WORK:

Mike started writing the FIFO_read module.

David was here and he and Mike spent some time debugging. We lowered the PLL speed to 250 MHz and verified that the counter (sum bits, at least) is still working, and that the rise-time output from the PULSE_CAP module is working. Then we tested the handshake signals and realized that the producer handshake was not working. Mike looked back at his code and realized that he neglected to put an explicit dual-edged DFF driving the producer handshake output, so it was trying (and of course failing) to shake the producer's hand continuously during the RAISE_HS state, instead of toggling it just once. Mike fixed that, and how the test works - the time-difference output from the PCAPTEST module holds steady at hex 0A (10 decimal). Now trying to ratchet the clock back up. Unfortunately, at multiples of 50 MHz, the highest speed at which the PULSE_CAP module seems to be working reasonably reliably is only 250 MHz. Still, with the dual-edged architecture, that gives us 2-ns resolution, so at least we're within striking range of the 1-ns target. But, further optimization of the PULSE_CAP module may be necessary.

Scope trace showing (bottom to top): (Yellow) Internally generated test pulse (20 ns width); (light blue) Producer handshake signal from pulse-capture module (toggles on data ready); (pink) Consumer handshake signal from pulse-capture test module (toggles on data received); (blue/green lines) low 8 bits of time difference, in 2 ns half-cycles, between rising and falling edge times, (purple) binary value of bits = hex 0A = decimal 10.

Some other next steps: (1) Test with externally-supplied input pulses from Ray's pulse generator again (our test pulses are kinda "cheating" since they are actually synchronous with our clock); (2) start writing the module to gather up the rise/fall times from all 6 comparators.