Testing, 1, 2, 3...

Today, one thing I want to do is to come up with a big list of things for the students to do, so that they can work a little more independently of me over the next couple of weeks.

First, I need to give them accounts on COSMICi, since they will need to be able to log into it to burn designs through the ByteBlaster cable. (Either that, or we need to get the XP installation on the Acer PC working again.) And I need to show them how to start up the Altera license server.

Here are some things the students can work on:

1. Write a test rig for the module they just finished (pulseform_cap). This can include the following:
   
   (a) An input stub that periodically generates a "fake" set of waveforms for all 6 thresholds, as if there was a triangle pulse coming in from the PMT input. It should scan through the number of threshold crossings: e.g., first generate a 1-threshold pulse, then a 2-threshold pulse, ..., up to a 6-threshold pulse, and then back down to 1. This will ensure pulseform_cap is exercised in all these test cases.
   
   (b) An output stub that sends the data packet from pulseform_cap sequentially, in 16-bit chunks, say, out to the digital scope. (They will need to identify 8 more output pins, or else just send the data in 8-bit chunks.) Send data most-significant word first, so that all 4 words (4 hex digits each) making up each 64-bit value will be in the same order on the scope as if they were written on paper (this will make them easier to check). Another tweak: If the leading-edge time for crossing threshold 1 is subtracted from all the values before outputting, then all the higher bits will be stable (at 0), and so the results will easier to read, and in fact, we could then get by with outputting only the lower bits - maybe just 1 byte for each threshold-crossing.
   
   Then, they just need to capture a sequence of data values on the scope for each of the 6 test cases, and verify by hand that the all the values returned make sense given the timing and height of the fake input waveform that was generated.
   
   
2. When that's finished & working, they can then work on testing with "real" analog pulses from outside. That will include the following steps:
   
   (a) Put Sachin's code back in - we will need it to set the thresholds in Labview.
   
   (b) Run Labview on PC (we'll need XP again for this), set thresholds, test with multimeter.
   
   (c) Connect an external source (e.g., waveform generator, generating triangular pulses) to one of the PMT inputs of the board (I suggest PMT_1). Identify the 6 LVDS input pins that serve as the comparators to detect threshold crossings for this input.
   
   (d) Verify that the sequence of values returned by the test stub makes sense, given the parameters of the external pulse. Vary the pulse height and width using knobs, and check that the output data varies accordingly.
   
   
3. Finally, they can test their stuff together with the FIFO and the Nios firmware (C code) that I (Mike) will be working on in the meantime.
   

My plan for this at the moment is:

1. To reduce the number of PIOs that will be needed, define a new sequential module to break the data into 32-bit chunks, and send them, one at a time, to a single data-input PIO. The CPU can toggle a control signal to "pump" the data out of my sequential module, one word at a time. For a pulse that did not even cross all the thresholds, we can just send data for the thresholds that were crossed.
   
   
2. Modify the Nios system design in SOPC builder to include the needed PIOs. These will include (at this point, in the envisioned design), for each PMT input:
   
   (a) An 8-bit output-only PIO, used bitwise for control of the datapath. Bits to include:
   
   * RUN_PAUSEn - Suspends the entire datapath when asserted.
   * PUMP_DATA - CPU raises this to cause the datapath to transmit the next word of data to the data-input PIO. CPU lowers this when it is finished reading that data word.
   
   (b) An 8-bit input-only PIOs, used bitwise to receive various status & interrupt signals from the datapath.
   
   * BUF_FULL - The FIFO is full, and so some pulse data may be being lost.
   * HAVE_DATA - Asserted when there is data for the current pulse left to stream. De-asserted when done.
   
   (c) A 32-bit input-only PIO, used for streaming of pulse data from the datapath, one 32-bit chunk at a time.
   
   
3. Write the C code to receive the pulse data. This will include the following tasks:
   
   (a) Write the code to set up and receive the interrupt, which will get triggered when the producer handshaking signal (HAVE_DATA) from the IC datapath (indicating new pulse data is available to stream) is asserted.
   
   (b) Write the code to pump the PUMP_DATA signal, read the words from the datapath, and put them together. (The code can verify that after the data for all the levels is received, HAVE_DATA goes low shortly after.)
   
   (c) For testing purposes, we can output the PMT data words in decimal (ASCII) to the serial port.

2:59 pm - I finished step 1 above, i.e., created a VHDL module "stream_pulse_data" that will stream the pulse data to the CPU one word at a time. Next, I need to add the appropriate PIOs to the Nios system ("FEDM_NiosSys") in SOPC Builder.