Following the Datapath...

Today the plan is just to continue with the detail design of the input capture datapaths.

I'm thinking that perhaps I could ask the students to do the detail design of the simpler IC datapath for the timing sync pulse, while I continue working on the more complicated one for capturing the PMT pulse waveform.

I brought a parallel cable in from home, since our ByteBlaster cable is not long enough, making testing awkward at present, but I need a F/F gender bender for it. Maybe I can pick one up at Fouraker's or Radio Shack on the way home this evening - need to leave early though to do that, since Fouraker's closes at 6, if I recall. If not I can swing by on my way in to work tomorrow.

Getting reading to write the FIFO_writer and FIFO_reader modules. Studying the FIFO datasheet (SCFIFO, synchronous variant). From the timing diagrams, it looks like the I/O should be done on the falling clock edge, so that all levels are valid on the rising edge when the FIFO module operates.

I finished writing the FIFO_writer module, although it is not yet tested. It is dual-edge-triggered, so that it can communicate with our other modules on the usual (rising) edge, while communicating with the FIFO on the falling edge as required by the FIFO datasheet. However, to enable me to still use variables & behavioral code in PROCESS statements, I compute the current state dynamically (i.e., combinationally) from a bunch of one-hot state flag variables which are each managed in pseudo-dual-edged fashion using the XOR trick.

The FIFO_reader module should be pretty easy, and rather similar to FIFO_writer in its internal design. All it needs to do is:

1. Wait (on falling edges) for the FIFO to be non-empty; and then...
2. Raise the RDREQ signal for one cycle to read out one data packet from the FIFO; then...
3. Place the data on the output lines and assert a signal that (via a control-register PIO) generates an IRQ telling the CPU that there is data ready to read; then...
4. Wait for the CPU to assert a bit (in a PIO control register) telling us that it has finished consuming the last data packet that we sent; then...
5. Return to the initial state (waiting again for the FIFO to be non-empty).

It would probably be safe for FIFO_reader to be entirely falling-edge-triggered, since besides the FIFO, the only other thing it communicates with is the set of PIO devices on the Avalon bus, and those devices are designed to be able to handle asynchronous input anyway.