1 Programming of FPGA in LiCAS ADC for Continuous Data Readout Week 5 Report Tuesday 29 th July 2008 Jack Hickish

2 Progress Last Week Both Continuous and Burst modes working correctly (qualitatively)‏ Some anomalies when comparing output to internally generated 'test mode' pattern. Began considering diagnostic systems to indicate data overflow - such systems require a serial interface with the USB chip to free some connections with the FPGA

3 Since then… SPI (Serial Peripheral Interface)‏ - Requires only 4 connections between USB and FPGA - 2 – way communication controlled by USB, with FPGA acting as slave - bit stream fed between host and slave, with a clock pulse on each bit

4 Since then… SPI (Serial Peripheral Interface)‏ 1) The master changes the state of SSEL down to indicate to the slave that communication is starting 2) The master toggles the clock eight times and sends eight data bits on its MOSI line. At the same time it receives eight data bits from the slave on the MISO line. 3) The master returns SSEL to its original state to indicate that the transfer is over.

5 SPI SPI will use existing parallel infrastructure inside FPGA. Bits are clocked in one at a time and then placed on an existing bus. Once bus is full a pulse activates the current parallel interface registry writing mechanism.

6 SPI Our USB controller chip has inbuilt SPI functionality - inbuilt clock and co-ordinated input and output lines Unfortunately these lines aren't connected to the FPGA. I have implemented a simplified interface with a pulse sent along with each piece of data, rather than a synchronised clock signal Effectively the same, though transferred bits are not always evenly spaced in time (but are always in sync with pulses)‏

7 SPI Interface currently has same functionality as previous parallel interface. Commands are identical from the point of view of the GUI (or Ian's interface) providing the updated hex file is loaded to the USB controller. (The hex file translates commands from the user interface into events on the input and output lines of the controller)‏ FPGA and USB controller are set up to receive full and empty flags for all the significant components in the FPGA. These bits sit in the USB waiting for the PC to request their transfer (I have yet to work out how to make this request)‏

8 Sampling & Averaging The ADC should be able to average over relatively long time periods (~1 second). This equates to an average over ~3 million samples. The FPGA was set up for averaging over a maximum of 128 samples, limited by the size of the accumulator, bit shifter (divider) and registry holding the value which sets the downscaling ratio. Rather than increasing the size of the size of the 8 bit register (would need to be extended to 22 bits wide to contain a number as large as 3 million) I edited the system so that when the register holds a value of n this corresponds to a downscaling ratio of 2 n rather than simply n. This means no new registers need be created and all existing 8 bit buses used to carry the registry values are still adequate

9 Sampling & Averaging FPGA is now set up for averaging over large times bit accumulator (can sum bit samples)‏ - 14 bit divider Initial Problems with available resources on the FPGA - Initially 150% of some resources used, preventing compiling - Experimenting with different algorithms for division and accumulation, this has been reduced to 99% - The program can be uploaded to FPGA, but leaves little overhead for other modifications

10 Diagnostics SPI allows diagnostic data (cache full flags) to be sent to PC via USB interface. Any diagnostic system must be able to - Signal after data acquisition if there has been any data loss And preferably - Indicate which parts of the data are unreliable

11 Diagnostics - Signal after data acquisition if there has been any data loss This is possible with simple SPI system currently implemented, providing the PC and USB controller can be interfaced (a question of syntax)‏ - Indicate which parts of the data are unreliable This is harder to achieve, requires either - editing data to include a reliable/unreliable flag - uses bandwidth by adding a bit to each piece of data - writing identifiable meta data to indicate overflow (e.g. ouput a string of '0's to indicate presence of full flag)‏ - real data lost when outputting meta data - requires intercepting data stream with 'if' clause, and slows FPGA performance - Have a counter running – flags can be referenced to this counter and hence to stage of data acquisition - Counter would need to be large => Resource intensive

12 Fix USB-PC Communication Decide on, and implement a diagnostic system, probably requiring some optimisation of existing code to free resources Experiment with capabilities of ADC at different downscaling ratios Start using Ian's new interface, maybe adding more (or watching Ian add more) functionality (user input values for main ADC operational parameters)‏ The Week Ahead...