Pulse Width Capture Testing

Turned in my timesheet today but it was late again... They're due Mondays this summer, due to the compressed furlough schedule. :(

Finished placing the requisition for the SMA connectors we need, asked Ray to approve it ASAP.

Got an email from Vaibhav, saying he will be available to help looking forwards.

Tyler and David are here, and I've asked them to start designing a new module pulse_cap_test.vhd to test the pulse_cap module - simply by copying the input data to input registers, adding the sum and carry bits, and writing the result to output registers. Then we can send a pulse of known width into the signal input pads with the waveform generator, and look at (say) the low 8 bits of each output register, or (measuring one at a time) the low 16 bits. If, say the input pulse is 10 ns wide, then at 450 MHz there should be 9 counts in between leading and trailing edge. Actually, even better, we can subtract (trailing - leading) in the test module itself, and then just observe the difference between these, as up to a 16-bit number. So in this test, we should be able to measure pulse widths up to about 72.8 microseconds (delta of 65,535 half-cycle time steps, each 1.11... ns at 450 MHz).

Mike is doing some filing while Tyler & David are working on that.

OK, got my desk cleared off. Now I am working on implementing the next group of modules for the PMT datapath. Here is what I have envisioned currently: An intermediate-level module our_FIFO that includes 3 submodules:

1. FIFO_writer: Consumes a data packet from pulseform_cap and inserts it at the tail of the FIFO queue. If the FIFO is full, asserts a complaint signal (BUF_FULL) which can be serviced by a CPU interrupt (to generate a warning in the serial text output stream to tell the system operators that some pulse data may have been lost).
   
   
2. pulseform_FIFO: This is just a generic FIFO megafunction variation. It is 774 bits wide and (for now) 16 stages deep. 774 = 6x(1+128), since we have 6 thresholds, and for each threshhold we have 1 "crossed" bit and 2*64=128 bits to indicate the leading/trailing edge time. Note that, if needed, we could compress the representation significantly (and thus, save memory in the FIFO) by storing a 64-bit "base" time, and then say 8-bit offsets from this for all the time values. This, however, assumes that we will never see a pulse more than 256 ticks long (about 284 ns). Is this a good assumption? Probably, but I'm not certain yet... Need to ask Ray at some point. Let's wait and see if we run into memory problems first though.
   
   
3. FIFO_reader: Consumes a data packet from the FIFO, and then delivers it to the CPU via a set of PIO interfaces. The actual data can be delivered in a set of twelve 32-bit input-only PIOs, with all handshaking done via a single 8-bit bidirectional control PIO, as envisioned earlier. Oh, and the "crossed" bits can be delivered in another 8-bit input-only PIO.

So far, I created the FIFO megafunction variation, and started wiring up the top-level our_FIFO schematic. (Doing it as a schematic rather than VHDL since it itself doesn't require any logic.)