1

Programming of FPGAin LiCAS ADC for

Continuous Data Readout

Week 5 ReportTuesday 29th 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

SPISPI 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 2n 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.

- 36 bit accumulator (can sum 222 14 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...