MONALISA ADC/FPGA Documentation - University of Oxfordmonalisa/open/pages/projects/SummerProjects... · Figure 2: Burst mode data path through FPGA, with FPGA data inputs and outputs

MONALISA ADC/FPGA Documentation

Jack Hickish

August 24, 2008

Abstract

Over the Summer of 2008, the FPGA in the LiCAS ADCs was modified to allow continuous datareadout, and other additional features were implemented. This document is an introduction to thenew MONALISA ADC for those both familiar and unfamiliar with the original LiCAS ADC.

Contents

1 Introduction to the LiCAS ADC 31.1 ADC Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 The Original LiCAS ADC (Burst Operation) . . . . . . . . . . . . . . . . . . . . . . . 31.3 Continuous Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1 FPGA Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.2 New FPGA Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.3 Cypress USB Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Operation Guide 152.1 Command Hierarchy & Default Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 User Parameters & FPGA Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Individual Channel Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Global Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3 Amplifier Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Diagnostic Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Testing the new ADC 233.1 Speed Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Warnings and Notes 25

5 Resources 275.1 FPGA Firmware Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Version 1 - Better Sampling Flexibility . . . . . . . . . . . . . . . . . . . . . . . 275.1.2 Version 2 - Better Averaging Capacity . . . . . . . . . . . . . . . . . . . . . . . 275.1.3 Version 3 (BETA) - Better Data Integrity . . . . . . . . . . . . . . . . . . . . . 28

5.2 Uploading Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 USB Firmware versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Other Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A FPGA Inputs & Outputs 33

1

CONTENTS 2

B FPGA Code 34B.1 Rogue Data Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34B.2 SPI bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35B.3 fake data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38B.4 Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

C Cypress USB Code 46C.1 store data function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46C.2 receive only function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1 INTRODUCTION TO THE LICAS ADC 3

1 Introduction to the LiCAS ADC

1.1 ADC Hardware

The LiCAS ADC uses an onboard Field Programmable Gate Array (FPGA) chip to manipulate data,as well as on-board RAM and FIFO storage blocks to buffer data before it is sent out via USB to acontrolling PC. The following is a brief overview of the ADC board and its operation at a hardwarelevel, giving the structure of the current, modified LiCAS ADC.

For the purposes of this document, the ADC’s onboard FPGA and USB Controller Chip will beregarded as the only programmable components in the ADC1

The specifications of the ADC are given in Table 1 below, and give the current capabilities of theFPGA. Note that for a given operational setup multiple specification constraints are applicable. Forexample the maximum number of samples per burst limit of 4.3 billion would generate over 500MBof data per channel, and is therefore incompatible with the maximum data per burst limit of 64MB.These specifications are given nonetheless, and give some idea of the performance of the ADC.

Internal Clock Frequency 50MHzNumber of Channels 16

Sample Resolution 14 bitMaximum Sample Rate 2.77MHz per channelMinimum Sample Rate 5.3Hz per channel2

Modes of Operation Continuous & BurstMaximum Data Generation Rate 88.6 MB/sec (Burst mode only)

Maximum Continuous Output ≈ 20MB/s (see Section 3.1)Maximum Samples per Burst 232 (4.3 billion) per channel

Maximum Data Generation per Burst 64MB total over all channelsDownscaling Method Sample or Average (Set individ-

ually for each channel)

Table 1: ADC Specifications

1.2 The Original LiCAS ADC (Burst Operation)

The original LiCAS ADC was set up to collect Frequency Scanning Interferometer (FFI) data, and assuch was required only to collect a fixed amount of data at a time, which could be stored in internalmemory before being output via USB to a PC. A pictographic representation of the data path throughthe ADC is given in Figure 1. A schematic of the data flow into and out of the FPGA chip, withrelevant ports labelled is also given in Figure 2.

The stage of data aquisition in burst mode are as follows (key FPGA components are given foreach stage, and are descibed in more detail later in Section 1.4.1):

1. Signal enters FPGA

Analogue Data is sampled and the digital signal passed to the FPGA. The signal entersthe FPGA in serial, with 14 bits per sample. There are 16 seperate lines into the FPGA,with one sending data from each channel.

16 complete samples (one from each channel) enter the FPGA every 18 clock cycles, thusgiving the maximum sampling rate of 50Mhz / 18 = 2.77 Mega samples per channel.

Key components: convert control.

1The ADC also contains a FIFO that has some level of programmability in the form of programmable full and emptyflags, and a RAM controller, that is in itself another FPGA chip. These have not been investigated or developed in any way.


Figure 1: Burst mode data path

2. Data Manipulation

Within the FPGA, the serial inputs from each channel are converted to parallel signals,with a 14 bit wide bus carrying data around the FPGA. A different channel drives the busevery clock cycle, with 2 spare clock cycles in every 18.

Data is downscaled inside the FPGA, subject to user input parameters. The FPGA iscapable of outputting every nth sample (sampling mode), or outputting the result of anaverage over every n samples (averaging mode).

Key components: convert control, data cpu.

Data saved to RAM

The downscaled data is saved to an onboard RAM chip. It is buffered into RAM throughan external FIFO. (This document uses the term “External FIFO” to refer to the dedicatedFIFO chip on the ADC board).

Key component: fifo controller

4. Data Output

When sampling is complete (Key component: aquisition control), and all the data is inRAM, the information is sent to the USB Controller, where it is requested by a hostPC. Data is buffered into the USB controlled via an internal FIFO. (The term “InternalFIFO” will be used to describe the FIFO that is generated within the FPGA from FPGAresources).

Key component: fifo8192 17.

This setup allows the ADC to be run at its maximum speed, although the amount of data that canbe generated in any given burst is limited by the amount of available RAM space. The current LiCASADC has 128MB of RAM, but limitations on the C++ code controlling USB data requests mean thatin practice a burst cannot exceed 64MB. These software limitations are quite possibly avoidable.

The original LiCAS ADC had no functionality for continuous data output at any speed.

1.3 Continuous Operation

The brief for the Summer 2008 FPGA project was to reprogram the FPGA so that the data could becontinuously read out from the ADC and written to disk. It is to this end that other modificationshave been made to the FPGA, including a new serial communication interface, a new continuous errorchecking mechanism, and extended downscaling capabilities.

When the ADC is run in continuous mode, the data path through the on board components isnecessarily different to that in burst mode. Since no data need be stored, other than for buffering


Figure 2: Burst mode data path through FPGA, with FPGA data inputs and outputs. Note that theserial input is separated into sdo long and sdo short, corresponding to channels 1-4 and 5-16 respectively.The distinction was made in the original LiCAS setup, but has no significance in terms of signal processingwithin the FPGA or ADC board

purposes, the onboard RAM chip is no longer used. It is however, desirable to have the maximumpossible buffering between the FPGA and USB output interface, as the USB protocol is bursty inits data transfer, requiring data to be requested by a host (PC) in chunks. There is no facility for acontinuous USB transfer other than sending repeated requests for data.

The first 2 stages of data aquisition are the same in continuous mode as in burst operation. Thedata is sent into the FPGA along 16 serial interface lines between the FPGA and the Digital converter.In the FPGA the data is downscaled, being averaged or downsampled as desired. It is at this pointwhere the continuous data path differs from the burst. Figure 3 gives a representation of the datapath in continuous mode, whilst the following gives a simple description.

1. Signal enters FPGA & 2. Data Manipulation

As for burst operation.

3. Data Buffering Stage 1

The downscaled data is buffered in the external FIFO.

Key component: fifo controller

4. Data Buffering Stage 2

The output from the external FIFO is buffered again, into the internal FIFO.

Key component: fifo8192 17.

5. Data Output

Whenever there is room in the USB transfer buffers, data is shifted from the internal FIFOto the USB controller, where it is written to disk after being requested by a host PC.

Key component: usb write control.

This setup is not limited in the volume of data that can be generated in any given acquistion run.However, the method of writing data to disk - that is, requesting a finite amount of data over USB,receiving this data and writing it to disk, requesting another chunk of data etc. - means that there aresignificant gaps in data uptake by the host whilst disk writing is taking place and no transfer requests


Figure 3: Data path in continuous operation

are being made. It is necessary for the FIFOs to store all generated data whilst none is being output,hence the limited size of these FIFOs places a limit on the data generation rate. For more details onthe speeds available in continuous mode, see Section 3.1.

In order to ensure that if data does overflow the buffers, the operator is aware of the extent oferrors, diagnostic features have been implemented alongside the new operation mode. Full details ofthese are in Section 2.3

The external FIFO will hold 512k samples before overflowing, whilst the internal FIFO will hold8096. Trials using just the internal FIFO showed that 8096 samples was not an adequate buffer forreliable operation at any but the lowest speeds, and for this reason the significantly larger externalFIFO was also employed as a buffer. The reason for keeping the internal FIFO as the last buffer beforethe USB controller comes down to simplicity of reprogramming, but has the benefit that the externalFIFO empty flag (which is connected to an LED) now serves as a useful performance gauge. Forreliable operation, the external FIFO should spend much of the time empty, and this can be checkedby simply looking at the board’s LEDs.

1.4 Firmware

Other than interface software on a host PC, further programming of the FPGA and the USB ControllerChip are also required. This section gives a brief overview of the current for each, and a morecomprehensive description of the new code which has been added to the FPGA this summer.

1.4.1 FPGA Components

The FPGA is programmed in VHDL (Very High Speed Integrated Circuit Hardware DescriptionLanguage). In this language, code is used to specify an entity with input and output ports, and describehow the entity should behave by specifying its architecture. When specifying an entity’s architecture,one may describe input dependent behaviour directly (i.e. when inputs are x, set outputs to y etc.),or build the entity from sub-entities, or components, which themselves have a definition in terms ofin/out ports and an architectural description. These components may be built from sub-components,and so on. It is this hierarchical structure which underlies VHDL.

A schematic of any given level of the hierarchical structure may be generated using the XilinxISE software. These schematics show the components at a given level and the signals which connectthem, and are extremely useful when trying to grasp the overall behaviour of a particular structure.The top level schematic is given in Figure 4, with each component labelled, and key ports and databuses highlighted. The following is a short overview of the behaviour and purpose of each of thecomponents in the diagram. To make small modifications to the system, such a basic understanding isoften all that is required. More details of new components and control signal mux units can be foundin Section 1.4.2.


ALIAS

INV

clock

reset

sim_adcconv

fake_sdolong(3:0)

fake_sdoshort(11:0)

OR2B2

AND3B3

AND3B1

AND3B2

AND3B2

AND3B1

AND3B2

INV

INV

load(15:0) load_fifo

fake_long_data(3:0)

fake_short_data(11:0)

real_long_data(3:0)

real_short_data(11:0)

mode

long_out(3:0)

short_out(11:0)

dp(223:0)

pc(7:0)

pe(7:0)

CLK

go_data_scan

loadm

reset

adcchan_data(17:0)

address(7:0)

data(7:0)

load_formater(15:0)

reg_con(7:0)

I

IB

O

AND2

data_in_ffi(17:0)

data_in_fsi(15:0)

ffi_mode

data_out(15:0)

ext_fifo_empty

ffi_mode

fsi_wen_in

int_fifo_full

wen_out

AND2B1

INV

counta(0)

din(0)

signald_or0000

signald(0)

counta(1)

din(1)

signald_or0000

signald(1)

counta(2)

din(2)

signald_or0000

signald(2)

counta(3)

din(3)

signald_or0000

signald(3)

counta(4)

din(4)

signald_or0000

signald(4)

counta(5)

din(5)

signald_or0000

signald(5)

counta(6)

din(6)

signald_or0000

signald(6)

counta(7)

din(7)

signald_or0000

signald(7)

counta(8)

din(8)

signald_or0000

signald(8)

counta(9)

din(9)

signald_or0000

signald(9)

counta(10)

din(10)

signald_or0000

signald(10)

counta(11)

din(11)

signald_or0000

signald(11)

counta(12)

din(12)

signald_or0000

signald(12)

counta(13)

din(13)

signald_or0000

signald(13)

counta(14)

din(14)

signald_or0000

signald(14)

GND

CLKIN_IN

RST_IN

CLKDV_OUT

CLKIN_IBUFG_OUT

CLK0_OUT

CLK180_OUT

LOCKED_OUT

INV

AND2

INV

INV

INV

q(17:0)

clkin

dataclk

ef

ff

ffi_mode

full

hf

int_fifo_full

load

pae

paf

reset

wen_overide

fifoout(17:0)

fs(1:0)

asyr

asyw

be

fwft

ip

iw

ld

mrs

oe

ow

pfm

pktend

prs

rclk

rcs

ren

sclk

sen

slwr

wclk

wcs

wen

sdolong(3:0)

sdoshort(11:0)

aquire

clk

dataclk

reset

d0(13:0)

d1(13:0)

d2(13:0)

d3(13:0)

d4(13:0)

d5(13:0)

d6(13:0)

d7(13:0)

d8(13:0)

d9(13:0)

d10(13:0)

d11(13:0)

d12(13:0)

d13(13:0)

d14(13:0)

d15(13:0)

adcconv

go_scan

load

address(7:0)

d(7:0)

aquire

clk

ext_stop_in

ext_trig_in

reset

sample_clk

sdram_empty

counta(31:0)

register33_out(7:0)

go_take_data

unload

unload2

clk

rst

sdram_ef

unload

usb_full

sdram_ren

usb_slwr

pcbus(7:0)

pebus(7:0)

clk

reset

si1

clk2

loaded

so

fifo8192_16bitdin(15:0)

wr_en

wr_clk

rd_en

rd_clk

rst

dout(15:0)

full

prog_full

empty

flags(7:0)

MOSI

reset

SCK

SSEL

parallel_out(15:0)

MISO

data_in(17:0)

data_clk

fifo_ff

load_fifo

reset

output(17:0)

wen_overide

ffi_mode

sdram_wen_in

sdram_wen_out

C

D Q

FD

C

D Q

FD

C

D Q

FD

I

IB

O

ALIAS

ALIAS

adcclk a2dclks(15:0)

cy_wr

full

sdram_empty

sdram_ff

hex(3:0)

sdolong(3:0)

sdoshort(11:0)

lvds_trigp

lvds_trign

queue_empty

fifo(17:0)

data_out(15:0)

ef

bkpt

cy_psen

cy_rd

ff

hf

pae

paf

stop

si1

MOSI

SCK

SSEL

lvds_clkp

lvds_clkn

clk1

cy_ea

cy_rama16

a2dclks(15:0)

cy_ramce

rd_clk

wr_clk

bkmonled

cy_ramoe

daq

idle

ifclk

data_in1(15:0)

fs(1:0)

asyr

asyw

be

fwft

ip

iw

ld

mrs

oe

ow

pfm

pktend

prs

rclk

rcs

ren

sclk

sen

wclk

wcs

wen

adcconv

unload

ren_sdram

CLK2

so

dout_int(15:0)

MISO

d(17:0)

wen_sdram

led1

led2

sdram_reset2

cy_ramwr

counta(15)

din(15)

signald_or0000

signald(15)

AND2B1

counta(16)

din(16)

signald_or0000

signald(16)

INV

counta(17)

din(17)

signald_or0000

signald(17)VCC

INV

hex(1)

hex(2)

hex(3)

cy_reset

full

led1_cmp_eq0000

led1_cmp_eq0001

led1_cmp_eq0002

led1_cmp_eq0003

led1_cmp_eq0004

led1_cmp_eq0005

loaded

sdram_ff

led1_mux0001

hex(1)

hex(2)

hex(3)

empty

led1_cmp_eq0000

led1_cmp_eq0001

led1_cmp_eq0002

led1_cmp_eq0003

led1_cmp_eq0004

led1_cmp_eq0005

led2

queue_empty

sdramplus_empty

sdram_empty

led2_mux0000

C

D Q

FD

FDR

C

D Q

R

sdram_reset

cy_reset

empty

usbfifoadr(1:0)

reset_in

slwr

fake_data

data_path

dcm_2

data_mux

data_cpu

fifo_controller

int_fifo_wen_mux

convert_control

aquisition_control

usb_write_control

top

fifo8192_16bit

SPI_bus

Diagnostics

sdram_wen_mux

led1_mux

led2_mux

TE

ST

MO

DE

GE

NE

RA

TO

RS

SERIALDATA

INFROMADC

DATA TOEXTERNAL

FIFO

DATA FROMEXTERNAL

FIFO

DATATO RAM

DATAFROMRAM

DATA TO USB

Figure 4: FPGA top level schematic


SPI bus - This is a new component, which converts the serial signals received from theUSB interface to parallel, where they are used to set register values in the FPGA. Thecomponent also outputs state flags to the USB controller, which can be requested from thehost PC.

dcm 2 - The DCM module is the source of the clock signals to other components in theFPGA. The DCM provides three clock signals, two at 50MHz with a relative phase differenceof π, and one output at 25MHz. The DCM input is from an external clock source.

fake data - fake data is a new component not present in the original LiCAS ADC. Thecomponent generates a test signal, which is a count up with unique starting point for eachchannel.

data mux - This component is a simple switch, passing either the test signal from fake dataor real data from the digital converter into the convert control module.

convert control - This component takes the 16 serial inputs from each channel (eitherreal data or generated test) and converts them into 16 14-bit buses.

data cpu - This component contains all of the data manipulation steps.In addition todata buses, inputs include buses carrying user-input parameters (sampling/averaging re-quirements etc.). Within data cpu are the accumulator and divider components which carryout averaging, as well as timing control components, which synchronise control signals inthe FPGA based on downscaling ratio.

aquisition control - The acquisition control component controls trigger and stop signalswhich control other processes in the FPGA. One of the most important components inaquisition control is counter32, a 32-bit counter which counts the number of samples to betaken in burst operation. Registers specifying operation mode (burst/continuous, real/fakedata) are contained within aquisition control.

Test Mode Generators - Data leaving the data CPU can be replaced by a sawtooth testpattern if desired. This pattern is sourced from counter32, and is placed in the data streamby the Test Mode Generators.

Diagnostics - This component is a state machine which monitors the health of storagecomponents in the ADC. Diagnostics intercepts data and places error information in thedata stream in the event that an error is detected. The output from Diagnostics which maycontain real data or error information is fed into the external FIFO on the ADC board.

data path - The data path component controls the source of data input into the internalFIFO. Effectively, this component invokes either the continuous operation path given inFigure 3 or the burst operation path shown in Figure 1.

fifo controller - This component generates the read/write control signals for the externalFIFO.

int fifo wen mux - This component controls the write enable signal to the internal FIFO,behaving differently depending on the mode of operation (burst/continuous).

fifo8192 17bit - This component is the internal FIFO. Its name reflects the FIFO depth(in words) and width. The internal FIFO is the last component in the FPGA that datapasses through, before it is sent to USB. The specifications of the FIFO are liable to change,based on FPGA resource limitations, and will almost certainly be reduced to a 16bit width.(The 17 bit width is a remnant of old code, and completely unnecessary and unused).

usb write control - USB write control halts data progress if the USB buffers fill up. Itsoutputs are only used in burst operation, as they control reading data from RAM.

sdram wen mux - This control signal mux prevents writing to RAM in continuous oper-ation.

Top - The top component controls communication between the ADC and the amplifiers,decoding user input commands and outputting them via a serial interface.

led1 mux - This unit controls the “FAULT” LED.

led2 mux - This unit controls the “DEBUG” LED.


Figure 5: SPI communication timing diagram

1.4.2 New FPGA Components

The following components were added in order to implement a continuous output mode. They aredescribed in more detail, with extracts of code where appropriate. A copy of the full code for the maincomponents (Diagnostics, SPI Bus, Fake Data) can be found in Appendix B.

SPI bus

It was desirable to have the ability to output status flags from the FPGA over USB. However, with theoriginal LiCAS setup all available (connected) signal lines between the FPGA and USB Controller werebeing used. 16 of these lines formed a parallel interfaced used to issue commands to the FPGA. Thesewere the “pc” and “pe” inputs on the FPGA. The current ADC employs a serial (SPI - Serial PeripheralInterface) interface to send these control commands, and thus only requires 4 communication lines,with the ability to both send and receive data. The SPI bus component accepts 16 bits in serial fromthe USB interface, and places these on a 16 bit bus. This bus then drives the infrastructure previouslydriven by the “pc” and “pe” inputs.

As with all serial interfaces, the SPI specification sends bits in a series and uses a clock (SCLK)to indicate the presence of a new information bit on the input line. The slave device also sends a bitof information to the host on each clock pulse, and thus the interface allows two-way communication.A timing diagram showing an SPI communication is given in Figure 5, showing the following stagesof communication.

1. The master changes the state of SSEL (Slave Select) down to indicate to the slave thatcommunication is starting.

2. The master toggles the clock eight times and sends eight data bits on its MOSI (MasterOut Slave In) line. At the same time it receives eight data bits from the slave on the MISO(Master In Slave Out) line.

3. The master returns SSEL to its original state to indicate that the transfer is over.

The system implemented is actually a modified SPI, with a few differences from that shown inFigure 5.

1. Our SCLK line is not a true clock with equal high/low times. It is actually a series ofpulses, synchronised with the data stream. This was simply for ease of implementation.The USB controller chip present on the ADC board does in fact have an integrated SPIinterface, though this uses ports currently unconnected to the FPGA. If te board were eversignificantly modified, use of these lines should be investigated.

2. The ADC system uses the SSEL as active high. Transmissions across the interface takeplace when SSEL = 1.

3. (IMPORTANT) Central to correct operation of the interface is the fact that althoughonly 16 bits are sent in each transmission (16 bits is merely a convenient choice for thepurpose of the interface, which can easily be extended or reduced if required) 18 SCLK


Figure 6: Simulation of a serial communication

pulses are required for a successful transmission from PC to FPGA. The final two pulsesare used to trigger the MSB of the “pc” bus to toggle high for a brief period. It is this pulsethat causes the information sent in the transmission to be written to the various registersin the FPGA. A simulation of a communication with the FPGA, where the “pc” and “pe”buses are filled with alternating 1s and 0s is shown in Figure 6. In this test the SCLKline is being simulated by a real clock signal - this is the case only in simulation. A signalrepresented by ‘U’ is undefined, and the simulation shows the two 8 bit buses being definedbitwise with each clock pulse. Note also the pulse on the ‘pc[7]’ line at 490ns, triggered bythe 18th and 19th pulses on the SCLK input.

In the simulation the FPGA can be seen to transmit a constant low signal on the MISO line. In thefinished SPI bus, with each received transmission, the FPGA sends 16 state flags to the USB controller,to later be requested by the host PC. The contents of these flags is explained in Section 2.3. The usershould be aware that whilst the flags are sent out of the FPGA to the USB controller whenever anytransmission is sent by the host PC, it is only when a dedicated “Receieve Only” command is issuedthat the USB buffers store this data and it can be retrieved.

Diagnostics

The Diagnostics component is a finite state machine which intercepts the data stream before it entersthe external FIFO, and is designed to survey the external FIFO full flag between data writes, and takeaction in the event the FIFO is full. The full code for the component can be found in Appendix B,but the underlying features are described here.

The state machine has 5 states; ‘ok’, ‘counting’, ‘info1’, ‘info2’, ‘info3’. The default state forhealthy operation is ‘ok’, and in this state the Diagnostics module does nothing, allowing data to pass


Figure 7: LTC1403A Timing Diagram

into the FIFO as normal.A transition to the state ‘counting’ is triggered if the FIFO full flag indicates that the external

FIFO is full. The FIFO write enable signal is immediately intercepted, preventing any further datafrom being written into the FIFO, and allowing the data backlog to clear. A pulse on the write enableline indicates a piece of data that could not be written to the FIFO and has been lost. Such pulsesare counted using an internal counter.

When the FIFO full flag (signal “ff”) indicates the FIFO is no longer full, after a preset delay(currently 50 clock cycles) to ensure there is space in the FIFO, Diagnostics enters state ‘info1’. Inthis state the internal counter stops, and a 16 bit piece of meta-data is written into the FIFO in theplace of a piece of real data. (Note that the count of missing data pieces takes into account pieces ofdata that are replaced with meta-data). Having written this data, state ‘info2’ is entered, and anotherword is written. The same happens again for state ‘info3’ whereupon the state machine returns tostate ‘ok’ and the counter is reset, ready for another overflow.

The contents of the 3 words of error data are explained fully in Section 2.3, but essentially comprisean error flag, record of volume of data lost and channel information required to continue recordingdata.

fake data

The fake data component was built to allow a thorough test of the FPGA, with test data fed in atthe earliest possible stage of processing. The component simulates the role of the Analogue-to-Digitalconverter, transmitting a 14 bit word in serial when triggered by the FPGA.

When Simulated Data Mode is entered (by setting the relevant registry bit - see Section 2.2) thetest pattern signal replaces the “sdo long” and “sdo short” signals in the FPGA. Seperate data isgenerated on each channel, and is a 14 bit count up, with the starting value equal to the channelnumber.

Timing the 14 bit serial output to be in sync with what the FPGA expects is vital, as the 14 bitsmust be transmitted on the correct 14 of 18 clock cycles. The timing of the FPGA is set up for theLinear Technology LTC1403A Analogue-to-Digital converter, and thus the timing requirements of thefake data module are determined by the specifications of the LTC1403A. A timing diagram for theLTC1403A is shown in Figure 7 and necessarily reflects the timing of the fake data component.

The strobe signal that controls the “CONV” in the LTC1403A is fed into the fake data port“sim adcconv”. When a strobe is detected, a state machine architecture results in a 14 bit transmissionafter the required delay on outputs “fake sdoshort” and “fake sdolong”.


Multiplexing Units

Since the data takes different paths through the FPGA depending on the mode (continuous/burstand simulated/real data) mode of operation, multiplexing units need to be intoduced to route datacorrectly. Control signals, such as read and write enable signals also need be changed based onoperation mode, and further multiplexing units carry out this task. Each multiplexing unit is controledby the value in one of the FPGA registers, which is fed into a “mode” input port on the mux anddetermines its behaviour. The following is a list of multiplexing units added, and the connectionsmade in different modes.

data mux

This unit selects between the simulated and real data streams, and is controlled by bit 3 of registeraddress 32 (simulated data bit).

Operation Mode Register Value Behaviour of data muxReal Data mode 0 real data passed into FPGA processing

unitsSimulated Data mode 1 Simulated data passed into FPGA

sdram wen mux

The SDRAM write enable mux controls the write enable signal for the external RAM modules. Itsbehaviour is controlled by the operation mode register (bit 2 address 32).

Operation Mode Register Value Behaviour of wen muxBurst mode 0 write enabled whenever external FIFO not

empty, and RAM not fullContinuous mode 1 write disabled always

datapath

Datapath controls the source of the internal FIFO input data. Control is via the operation moderegister (bit 2 address 32).

Operation Mode Register Value Behaviour of datapathBurst mode 0 Internal FIFO takes data from RAM

Continuous mode 1 Internal FIFO takes data from ExternalFIFO

int fifo wen mux

This mux controls the internal FIFO write enable signal based on the operation mode register (bit 2address 32).

Operation Mode Register Value Behaviour of wen muxBurst mode 0 write enabled when internal FIFO not full

and RAM not emptyContinuous mode 1 write enabled when external FIFO not

empty and internal FIFO not full

External FIFO read enable

There is no explicit component responsible solely for the mux of external FIFO read enable signals.However, this behaviour is incorporated into the fifo controller component, and is controlled by theoperarion mode register bit (bit 2 address 32). The read enable signal can be disabled by an overidesignal from Diagnostics in both modes of operation. This happens after the external FIFO becomes


full, to allow the FIFO to recover. The duration of the overide after the FIFO ceases to be full is setin the Diagnostics code.

Operation Mode Register Value Behaviour of read enableBurst mode 0 read enabled whenever external FIFO not

empty, and RAM not full (subject tooveride from Diagnostics)

Continuous mode 1 read enabled when external FIFO notempty and internal FIFO not full (subjectto overide from Diagnostics)

1.4.3 Cypress USB Controller

In order for any USB communication between a computer and the ADC board to take place, the USB‘Cypress’ controller chip in the board must be loaded with appropriate firmware. This is generated byC-code, and takes the form of a .hex file, generated under the name “adcusb.hex”. The correct hexfile is loaded to the Cypress chip by the data acquisition software, and contains setup information forthe chip (input/output specifications of ports) and the functions required to send commands to theFPGA.

Code required to generate a new .hex file is contained in the directory “C:\FPGA Summer2008\Source Code\Cypress”which contains the source code “adcusb.c” and headers “Fx2.h”, “fx2regs.h” and “fx2sdly.h”. Thiscode can be edited and rebuilt (using Keil - installer found in same directory), which will generate anew adcusb.hex file in the same directory.

The main functions specified in “adcusb.hex” are store data and bit set.

store data is a two argument function, which takes an address and value input. Thefunction writes the value given to the addressed register, overwriting all 8 register bits.

bit set is a three argument function. It also takes an address input used to specify aregister but rather than overwriting all 8 register bits, the two further arguments in bit setare used to specify a specific register bit and its desired new value.

As well as these two general functions used to write to registers, the hex file contains several pre-specified FPGA commands (most of which simply call bit set and store data in a specific order), thatare initiated when the host PC sends the appropriate command over USB. All commands are prefixedby “aa”, the command byte, whilst the next byte determines the function to be executed. Commandsare as follows:

0xff FPGA RESET Resets all aspects of the FPGA0xfe USB RESET Resets the USB controller. Following a re-

set a new .hex file must be downloaded0xfd SDRAM RESET Clears RAM0x02 STORE DATA Sent with 2 further values as arguments for

the store data function0x03 TRIGGER Triggers the FPGA to acquire data when

in internal trigger mode(default)0x04 ADC SETUP Sets up ADC to acquire data, loading de-

fault parameters0x05 DATA MODE Sets the acquire bit of register 32 (see Sec-

tion 2.2)0x06 TEST MODE Initiates Test mode (see Section 2.3)0x07 BIT SET Sent with 3 further calues as arguments for

the set bit function0x08 EP8 FIFO RESET Resets the USB buffer holding data ready

to be requested by host PC0x09 EXTERNAL TRIG Sets the ADC to External Trigger Mode


0xf1 CONTINUOUS Sets the ADC to acquire data continuously0xf1 BURST Reverts to burst acquisition operation0xf2 STOP Stops acquisition when in continuous mode

using dedicated stop line0x55 RECEIVE ONLY Writes FPGA state flags to USB buffer,

ready to be requested for transfer by a hostPC

0x66 FAKE DATA Initiates Simulated Data mode (see Section2.3)

The nature of store data and bit set functions has been completely reworked to allow serial com-munication between the USB controller and the FPGA. All original commands have however beenpreserved, so providing an up-to-date hex file is used (A hex file containing code for a parallel inter-face is absolutely NOT compatible with an FPGA set up to receive in serial!), previous ADC software(namely the original “Oxford DAQ” software) are still compatible with the new ADCs.

When developing acquisition software, at times it has been important to recognise that the serialinterface is not as fast as the parallel interface in sending data to the FPGA. If commands need tobe sent rapidly, it may be worth considering using a dedicated line between the USB controller andFPGA.

The new serial interface uses only 4 signal lines between the FPGA and the Cypress chip. Of the16 lines previously connected (8 lines from the PE Cypress ports and 8 lines from the PC ports) onlylines PC0-4 are currently used. 0-3 comprise the serial interface. PC4 is a dedicated stop line to theFPGA. If PC4 is held high for over 20 clock cycles (40ns) continuous data acquisition will halt. Thestop line was introduced to allow a rapid stop command to be issued to the FPGA, in the hope thatthere would only be a short delay between the connected computer ceasing to take data and the FPGAstopping generating data. This helps prevent the external FIFO from filling after the data acquisitionrun has effectively finished. The benefit of this is that error flags can be received from the FPGAwhich hold useful information. If the FIFO fills, the useful information is lost, as a data overflow maybe indicated, even though all the data obtained is sound. This is not a problem in burst mode, wherethe FPGA stop signal is generated automatically and internally.

2 OPERATION GUIDE 15

2 Operation Guide

2.1 Command Hierarchy & Default Settings

The commands in the previous section are used to control the ADC. As new commands have beenadded a command hierarchy has resulted, where commands must be issued in the correct order tobe effective. If issued in the wrong order, a command may write to a register that is subsequentlyoverwritten by a later command. This system was created semi-accidentally, but has the benefitthat software which has no ability to input some of the new commands can usually run with originalcommands with new settings set to default.

For example, an interface designed for the original LiCAS ADC that couldn’t issue the “CON-TINUOUS” or “BURST” commands to set the operation mode, could still use the original “ADCSETUP” command, which sets to the default operation mode (burst).

Command Order

In the current Labview acquisition software, some parameters are set via a GUI, whilst others aremerely entered into a text file. In this text file the order of commands is important. The followinggives the order commands should be issued, with the first commands at the top:

Reset FPGA“ADC SETUP”

Choose Burst/Continuous Operation modeChoose Test/Simulated data mode if required

Choose External Trigger Mode if required

Other parameters - sample/average mode, downscaling ratio etc. can be set after the above com-mands, and are usually built into acquisition software.

Default Setting

The “ADC SETUP” command sets all registers required for the ADC to run in default mode. If onlycommand ADC SETUP is issued before the trigger, the following default parameters are set after anautomatic reset.

Channel Selection - None by default (must be set by software)

Downsampling - No downsampling (full speed)

Operation Mode - Burst operation. Real data acuisition

Trigger Mode - Internal trigger

Number of Samples - 2048

2.2 User Parameters & FPGA Registers

This section describes the different external parameters which control operation of the ADC includingthe addresses of the FPGA registers. All user determined parameters are passed to the FPGA bysetting relevant register bits.

2.2.1 Individual Channel Registers

There are 16 ADC channels - each has two control registers, the Sample Register and the ControlRegister.


Sample Register

The Sample Register determines how ofter a channel is read out. A channel is read out every 2n

samples, where n is the value stored in the channel’s sample register. If a channel is in sample mode,it will read out every 2nth sample. If a channel is in average mode, it will read out the average overevery 2n channels. Sample and Average mode are set in the control register.

Note that the original LiCAS FPGA code would average over the value held in the sample register(n), rather than 2n. Therefore the full speed default in the original FPGA code was 1. The default inthe new code is 0. If the original FPGA code is used with a value of 0 in the sample register no datawill be taken.

Note that there are two versions of the Firmware, and only in one version can the sample registerbe set uniquely for each channel. See Section 5.1 for more details. The maximum value that can beset in the sample register is also different in each version.

ADC Address MSB LSBChannel 7 6 5 4 3 2 1 0

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

10 10

11 11

12 12

13 13

14 14

15 15

Control Register

The Control Register is used to Enable or Disable and set either Sample or Average mode foreach channel/

bit 0 = 0 Channel offbit 0 = 1 Channel on

bit 1 = 0 sample modebit 1 = 1 average mode


MODE ON

0 16

1 17

2 18

3 19

4 20

5 21

6 22


7 23

8 24

9 25

10 26

11 27

12 28

13 29

14 30

15 31

2.2.2 Global Registers

Global registers affect all channels. There are three global registers, the Acquire Register, TriggerRegister and Sample Count Register.

Acquire Register

bit 0: Must be set to 1 for the ADC board to acquire data

bit 1: FPGA reset. Set to 1 to reset the FPGA. This bit is cleared by the reset.

bit 2 = 1 Test Mode operationbit 2 = 0 Data acquisition operation

In Test Mode, ouput data is a countdown from the Sample Counter in a 14 bit window. If theSample Counter is greater than 0x3FFF then the counter rolls over and starts again at 0x3FFF.


TEST FPGA ACQ-MODE RESET UIRE

Global 32

Trigger Register

Bit 1 of the trigger register sets the trigger mode to internal or external. Bit 0 of the trigger registeris the internal trigger. It is operated by taking the bit from 0 to 1 and back to 0.

If the trigger mode is set to external, the FPGA is triggered by an external signal on the lvds trigpand lvds trign inputs. This trigger signal must be present for at least 20 clock cycles (400ns) to beeffective.

Bit 2 sets the ADC to continuous or burst mode. Bit 3 sets the ADC to real data or simulateddata mode.

bit 0 = 0 → 1 → 0 internal trigger command

bit 1 = 0 internal triggerbit 1 = 1 external trigger

bit 2 = 0 burst modebit 2 = 1 continuous mode

bit 3 = 0 real data modebit 3 = 1 simulated data mode



SIM. CONT. TRIG. TRIG-DATA MODE MODE GER

Global 33

Sample Count Register

The Sample Count Register determines the number of samples read out (burst mode only). It cantake any value up to 232. (Note that in burst mode only 64MB of data may be generated in eachburst). It also sets the initial value of the Test Mode countdown.


Global 64 BYTE 0

Global 65 BYTE 1

Global 66 BYTE 2

Global 67 BYTE 3

2.2.3 Amplifier Controls

The Amplifier parameters are set in the Amplifier Register and saved by writing to the AmplifierStore Register.

Amplifier Settings

Amplifier gain and AC/DC settings are set in register addresses 80 - 87 and have the following format.Each register is used to set the amplifier setting for two channels. Bits 0-3 hold information on theupper channel, and bits 4-7 hold information on the lower channel.

In each set of 4 bits, the MSB sets the mode to AC or DC, the middle 2 bits set a gain value, andthe LSB sets a gain multiplyer.

After setting the Amplifier Register, the Amplifier Store Register must also be set to savechanges.

Lower Channel Settings Upper Channel Settings

bit 7 = 0 AC operation bit 3 = 0 AC operationbit 7 = 1 DC operation bit 3 = 1 DC operationbits 6,5 = 0,1 Gain 1x bits 2,1 = 0,1 Gain 1xbits 6,5 = 1,0 Gain 2x bits 2,1 = 1,0 Gain 2xbits 6,5 = 1,1 Gain 4x bits 2,1 = 1,1 Gain 4xbits 6,5 = 0,0 Gain 8x bits 2,1 = 0,0 Gain 8xbit 4 = 0 No Multiplier bit 0 = 0 No Multiplierbit 4 = 1 Multiply Gain bit 0 = 1 Multiply Gain



AC/DC GAIN MULT. AC/DC GAIN MULT.

0 & 1 80 CHANNEL 0 HEXIT CHANNEL 1 HEXIT








Amplifier Store Register

To save the values written in the Amplifier Register, the Amplifier Store Register should be writtenwith zeros.


Global 88 0 0 0 0 0 0 0 0

2.3 Diagnostic Features

The ADC FPGA has several diagnostic features, which can be split into two distinct groups. Thefirst group comprises testing features, which allow the functionality of the ADC to be tested prior tobeing used in a real data acquisition run. These facilities proved extremely useful when modifyingthe FPGA, and will no doubt be used if future modifications are implemented. The second groupof diagnostic features comprise those which are used during a data acquisition run to record errors.There are two main error checking methods employed in the FPGA, with one method particularlysuited to each of the continuous and burst modes of operation.

Test Features

There are two test functions implemented in the FPGA, one function called Test Mode that wasavailable in the original LiCAS ADC, and a new function called Simulated Data Mode which to a largeextent replaces Test Mode.

Test Mode is entered by setting the test mode registry bit to 1, and causes the number of samplesrequested to be used as an initial value for a count down sequence. When in Test Mode the dataoutput by the FPGA is identical for all channels, and is a countdown from the sample number in a14 bit window. If the number of samples requested exceeds the hex value 0x3FFF (16383) then theoutput countdown will roll-over through zero to 0x3FFF and continue to decrement.

Test Mode cannot be used to test the averaging function3, as the test pattern is generated after theaccumulator/divider modules in the FPGA, but the signal is generated before any of the ADC storagestages, and thus can be used to check for FIFO overflow. It is also worth noting that the test signalgenerated is always identical for all 16 ADC channels, and thus can produce ambiguous results. It isimportant to recognise that data output from the ADC has no channel signature - as individual bytesare processed by the data acquisition software they are assumed to come from sequential channels. Assuch, a single lost piece of data can throw all the following data out of sync with its source channel.It is largely for this reason that the second test function was created.

3Test Mode may give the illusion of averaging by outputting every nth value of the countdown. This is merely a resultof the output enable signals of the FPGA pulsing at a lower frequency compatible with the averaging of real data. At nostage in the FPGA does the test signal go through the FPGA accumulators.


Simulated Data Mode generates a test pattern at the earliest possible stage in the FPGA whichis fed into the ADC along the “sdoshort” and “sdolong” input lines (see Fig. 2). This signal can thusbe used to test the entire data path through the FPGA, including averaging/sampling downscalingratios and ADC performance at different speeds. Simulated Data Mode is activated by setting therelevant registry bit to 1. The function generates a test pattern which has no user programmableparameters. The pattern is a count-up on each channel, with the initial value being equal to thechannel number being tested. (e.g. The output of channel 2 is 2, 3, 4 . . . and the output of channel6 is 6, 7, 8 . . . ) Note that for the purposes of the test, ADC channels are numbered from 0 to 15, notfrom 1 to 16.

Using Simulated Data Mode allows the integrity of data output to be more thoroughly tested thanusing Test Mode as the test pattern encodes the channel number that each piece of data should beassigned to.

Error Checking

There are two error checking methods available on the ADC. The first shall be referred to as FlagChecking, and is most suited to ADC burst mode operation. The second shall be refered to as Meta-data Checking and whilst effective in both continuous and burst modes of operation, was designedprimarily with continuous mode in mind.

Flag Checking is used after a data acquisition run has been completed, and allows the full/emptystate flags of critical ADC components to be checked. The user must first send the “Send Flags”command to the FPGA, and then the data acquisition software must seperately request the informationfrom the USB interface. It is important that there is a small delay between requesting the flaginformation from the USB and sending the “Send Flags” command.

Flag information is received in the form of two bytes. The first byte contains the states of the flagsat the time the “Send Flags” command was sent. The second byte contains all flags that have beenhigh since the last FPGA reset.

The format of the flag bytes is as follows (with all flags displayed as active high):

bit 0 Internal FIFO full flagbit 1 Internal FIFO empty flagbit 2 External FIFO full flagbit 3 External FIFO empty flagbit 4 RAM full flagbit 5 RAM empty flagbit 6 USB buffer full flagbit 7 Operation Mode flag 1 = Continuous 0 = Burst

Flag Checking is designed for burst mode operation. After data acquistion, a check of the historicalstates of the RAM and FIFO full flags indicates the success of the run. In burst mode, filling of theexternal FIFO or RAM is an indication of data loss. In continuous mode, filling of the external FIFOis an indication of data loss. The system is of limited use in continuous mode, since data acquisitionmust halt whilst sending the “Send Flags” command, in which time many components may becomefull.

Meta-data Checking is an automatic and continuous checking function that is built into theFPGA and is active in all modes of operation. The ADC generates data with 14 bit resolution, butoutputs 16 bits per sample, allowing 2 bits to be used as error flags. With these two bits, data outputfrom the FPGA can be tagged as any one of 4 types, marked with 00, 01, 10 or 11 in the MSBs of the16 bit output.

Three pieces of meta-data are generated whenever an overflow error is detected. When the errorhas cleared, these pieces of meta-data are output in the data stream via USB. They are designed toencode the number of pieces of data that have been lost during a period of data overflow, and channelinformation allowing data output after an error has cleared to be assigned to the correct channel.


Figure 8: Bitwise makeup of metadata

......

......

13484 592 1851 755213485 615 1812 761113486 631 1756 769215487 12 5666 100815488 34 5612 110115489 49 5551 1199

......

......

Figure 9: Example of ASCII formatted data for 3 channels. Index column on left shows 2000 samples aremissing from each channel

Figure 8 gives a graphic description of the meta-data makeup. The meta-data system outputs thechannel number of the last missing piece of data (NOTE: Last missing piece of data means that if thechannel number in the meta-data is (eg) 7, the first piece of data received after the error messageswill be channel 8. And remember that in this sceme channels are numbered 0 - 15) and uses a 37 bitcounter to record the number of pieces of missing data. An error flag is also used to indicate overflowof the error counter.

Meta-data is decoded by the acquisition software, which will output only the 14 bit data, withlost data indicated by gaps in row numbers. The channel information encoded in the meta-data isautomatically used to align data to correct channel columns after errors. This process is carried outby the C++ “reader” program, which is also used to convert data from raw binary format to ASCIIformat, with sample index and channels in columns. In this format, only complete rows are given (arow with some channels missing data is ignored). Errors are identified by discontinuities in the sampleindex column. Figure 2.3 is an example of ASCII formatted data with 3 channels of data, where 2000data points for each channel have been lost.

LEDs

The ADC board has 4 LEDs which can give immediate indication of errors. On the ADC board theseare labelled “IDLE”, “DAQ”, “DEBUG” and “FAULT”.

The first two LEDs represent the state flags of the external FIFO as follows


LED Flag Meaning

IDLE FIFO full External FIFO full when LED litDAQ FIFO empty External FIFO empty when LED lit

The “DEBUG” and “FAULT” LEDs are multifunctional, and can be set to give different outputsbased on a hex switch, but by default (hex = 1) give

LED Flag Meaning

DEBUG USB empty USB buffer empty when LED litFAULT USB full USB buffer full when LED lit

3 TESTING THE NEW ADC 23

3 Testing the new ADC

The Simulated data mode was introduced to the FPGA with the aim of creating the most thoroughtest of the FPGA firmware as possible, without requiring any additional hardware. The test modeshowed the FPGA to successfully output data continuously without damaging the integrity of thedata.

The simulated data mode was also used to test the FPGA accumulators and verified their correctoperation.

3.1 Speed Tests

The data acquisition software for the new ADC board has been continuously developing alongside theFPGA firmware, with software quickly becoming out of date before being tested. As a performancebaseline, a simplified version of the acquisition software was made, in which data was written to fileby the following method.

1. Open file.2. Receive n pieces of data over USB.3. Write these to file in ASCII format.4. Close file.5. Repeat continuously, overwriting file each time.

Figure 10 give some results of this test. A run is counted as successful if it can be carried outwithout the external FIFO filling (based on a check of full LED). The maximum acquisition rateachieved reliably was 1 channel at half speed, corresponsing to 1.4 million samples per second, or 2.8MB/s. Using all 16 ADC channels, this speed equates to an acquisition rate of 87kHz per channel. Atthis speed the acquisition software was run without errors for over 1.5 hours.

Figure 10: Data transfer performance at varying acquisition speeds

The success of an acquisition run is largely dependent on how much data is received and writtento disk in each loop. If too little data is acquired, the timing overhead of the loop itself causes the runto fail. However, there is also a maximum amount of data that can be successfully received in each

3 TESTING THE NEW ADC 24

loop - if this is exceeded, the time taken to write this data to disk before more can be received is toogreat, and the data overflows in the FPGA.

Since this test was carried out, an acquisition method was developed which writes to disk in rawbinary format. Initial results with this method show it to be possibly up to 8 times faster, and certainlycapable of taking data for 3 channels at full speed without errors over periods of order 1 minute.

It is worth noting that if data is not written to disk at all but is acquired over USB, the FPGAcan read out at least 7 channels at full speed without overflow. This may not be surprising, but atshows that USB bandwidth is not a problem if the delay in USB uptake caused by writing to file canbe reduced or removed (multithreading?).

Further note that the FPGA generates data at a maximum of 16 samples per 18 clock cycles (at50MHz). Data is only output from the FPGA 9 times per 18 clock cycles. It is thus important torealise that the ADC will never be able to output data continuously at full speed (16 channels at2.77MHz per channel).

4 WARNINGS AND NOTES 25

4 Warnings and Notes

Warnings

1. The Cypress controller code writes error flags to endpoint 1 (EP1IN) when the “RECEIVEONLY” command is issued. There is currently no check before writing that the end point is notcurrently in use. Some check of the endpoint busy bit should probably be added. This would bewritten in the adcusb.c file.

2. The Diagnostics module counts number of pieces of data lost using a 37 bit counter. This counterstarts at 4, to offset 3 bits of data lost whilst error information is being output, and also 1 bitof data lost before the Diagnostics state machine enters the “counting” state. The offset of thecounter has not been thoroughly checked for correctness. It is not inconceivable that the offsetmay be out by 1 either way. (This value is not used to re-align channel data after an error, onlyto give an indication of how many data pieces have been lost)

3. The error decoding software uses the channel information contained in the error meta-data torealign channel columns. It uses the error count information to increment the row index number.It does this by dividing the number of missing pieces of data by the number of channels usinginteger division. If the number of missing data pieces given in the error count is correct, thisinteger division should produce no remainder (partially full rows are taken into account), but ifit not the row index may be out by +/- 1 after an error. Initial tests using a recognisable datapattern showed that the row index was correct, but the potential problem was not investigatedfully.

Notes

1. It should always be remembered that data output from the ADC is not tagged with a channelnumber. Acquisition software on the PC side assumes that data will be received in an orderedfashion and assigns the data to channels based on this assumption. If a single piece of data islost, data will not be assigned to the correct channels. Worse, if pieces of data are lost in themiddle of acquisition, data from different channels will be mixed up. It is for this reason thatchannel information is sent in error meta-data after a data overflow.

2. In the original LiCAS ADC, when tested, the first data piece of any data acquisition run waserroneous. It appeared to be left over from the previous run and still present if the ADC ispowered off and on before acquisition. This piece of data does not replace any real data, butthe acquisition software would automatically allocate this data to channel 1 (or the first channelenabled). This results in columns of data not representing their assumed channels.

The new MONALISA ADC appears to also output 1 piece of erroneous data before that re-quested. To combat this, the new acquisition software ignores the first piece of data received inany given run. Testing the ADC with simulated data shows the output given this step gives thecorrect results, with the first channel data going into the first column, etc.

3. The data decoding software uses the error meta-data output in the data stream to re-aligncolumns and record the number of lost samples after an error. This data is contained in 3separate pieces of meta-data, all of which must be successfully received in order to piece backtogether the remaining data effectively. The decoding software DOES NOT check that it has all3 error meta-data pieces, but assumes that it will receive them in order. If it does not, resultsand formatting may be anomalous.

It should not be possible for the FPGA to fail to output these 3 error pieces(!). Data can onlybe requested from the USB buffer in multiples of 512 byte packets - 256 data pieces. Hence,if the FIFO is full, as soon as the next chunk of data is sent over USB, space for at least 256data points appears in the external FIFO, after a period of time equal to 256 read clocks. Errorinformation is not sent to the external FIFO until 50 write clocks (25 read clocks - the read clockis half speed) after the FIFO full flag indicates the overflow has been cleared. So there shouldbe more than enough space for the required 3 pieces of meta-data.

4 WARNINGS AND NOTES 26

Of course, meta-data could be lost to some other anomaly in the ADC system, and to safeguardagainst this it may be desirable to modify the formatting software to notify the user if a pieceof meta-data is missing. However, if the ADC is losing random pieces of data to a fault thatis not data overflow, the output data itself will be unreliable, regardless of meta-data integrity.A single lost piece of data that goes unnoticed throws the channel assignment of data from itscorrect alignment mixing up data from different channels. Loss of data in this way should beeasily identifiable using a test data pattern, but may be very difficult to detect in real data.

I should say at this point that no data loss of this kind has been seen whilst developing the ADC.

4. To compensate for the above problem, a possible modification is the following.

• The Diagnostics module has an 18 bit input which contains 14 bits of data tagged with 4 bitchannel number information. The Diagnostics module currently outputs error meta-datafollowing a data overflow, in the form of 14 bits of error information tagged with a 2 biterror flag. 3 pieces of meta-data are output tagged with “01”, “10” and “11” respectively.The module could be changed such that all pieces of meta-data use the “01” error flag.

• Use the then unused “10” tag to mark pieces of data from a given channel. The channel tobe marked could be set in a register.

• Register 33 has 4 free bits, and is already routed at top hierarchical level under name“register33 : std logic vector(7 downto 0)” - the acquisition software could automaticallywrite to this register instructing the lowest channel number enabled to be marked.

• The binary formatting software (C++) would need to be modified to deal with all errormessages having the same flag code.

• Program the formatting software to check that the marked channel is allocated correctly.(i.e. assigned to the first column).

Such a system would guard against channel data being mixed up, and is (relatively) easy toimplement4.

4firmware Version 3 (BETA) has a variation on the above method implemented (FPGA code only - no compatible decoderhas been made at this time), but has not been tested fully. See Section 5.1

5 RESOURCES 27

5 Resources

The following section gives the locations of all resources left behind at the end of the FPGA project.It includes source code, programming files and general documentation. There is also a brief guideexplaining how to upload new FPGA firmware.

5.1 FPGA Firmware Versions

Copies of source code for each of the firmware versions can be found in directory “C:\FPGA Summer2008\Source Code\FPGA”The relevant project file in all version cases is “11 08 08.ise”

Copies of programming files (including PROM files) generated by this source code can be found indirectory “C:\FPGA Summer2008\Programming Files”

As well as the versions discussed below. Source code is also available for the original LiCAS FPGA.This is named “adcusb ORIGINAL.zip”. Note that this isn’t truly the original LiCAS code, as it hadto be edited to compile properly. It is probably the case that a more up-to-date version of the LiCAScode is stored somewhere.

There are 6(!) versions of the FPGA firmware and source code. These are split into 3 versions,described below. Each version itself comes in two flavours. The “a” type, (e.g. “Version 1a”) and a“b” (“e.g. Version 2.b”). the difference between type “a” and type “b” is 1 very simple difference inthe definition of the USB write enable signal, but may prove extremely important.

All of the version “a” firmware appears to give out an erroneous error point at the start of everydata acquisition run. If this point is ignored all further data is correct and none is missing. Howeverthe requirement to receive data over USB in multiples of a fixed packet size mean that an offset of 1in the data makes generating multiple files of data from the same run unnecessarily tricky.

Version “b” of the firmware inserts a 1 cycle delay in the USB write enable signal, which appearsto solve the problem. The changed section of code is in the adcusb struct.vhd source file, and thedifference between this file in the two versions can be seen in Appendix B.1.

Version “b” firmware hasn’t been properly tested, merely given one test run late one Saturday night.It’s entirely possible that the bug hasn’t been fixed, but at first glance, the results are promising.

5.1.1 Version 1 - Better Sampling Flexibility

Version 1 of the FPGA Firmware allows the user to set each of the channels 0 - 15 to read out dataat a different rate by setting the Sample Register accordingly (See Section 2.2).

The user can also set each channel to either average or sample the data.Having a register to store a unique sampling value for each channel uses a surprising amount of

resources, and thus the averaging capacity (limited by the size of accumulators) is less than in firmwareVersion 2.

Firmware Version 1 allows averaging (or sampling) over a maximum of 2n (x) samples.

Version 1 Specifications

Maximum value that can be entered in the sample register for any channel: 15Maximum downscaling ratio: 32768 (215)Minimum data output rate per channel: 84.5 samples per second

5.1.2 Version 2 - Better Averaging Capacity

In Version 2 of the FPGA Firmware channel downscaling ratios are set in groups of 4 channels. Chan-nels 0-3 must average/sample over the same number of samples, channels 4-7 must average/sample overthe same number of samples, channels 8-11 must average/sample over the same number of samples,and channels 12-15 must average/sample over the same number of samples.

To set up Version 2 of the firmware, the registers that need setting are those corresponding to thechannels 0, 4, 8 and 12 Sample Registers (see Section 2.2). If other channels sample registers are setthese values will have no effect.

5 RESOURCES 28

ADC Address MSB LSBChannel 7 6 5 4 3 2 1 0Global 33 CHANNEL TO MARK SIM. CONT. TRIG. TRIG.

DATA MODE MODE

Table 4: Modified Trigger Register

Note that the user still has the ability to independently set all 16 channels to either averaging orsampling mode, as these parameters are not stored in the Sample Registers.

The benefit of grouping channels together in this manner is that fewer registers are needed, freeingmore resources for larger accumulators.



5.1.3 Version 3 (BETA) - Better Data Integrity

A third version of the FPGA firmware exists, that has not been tested, but implements “channeltagging”, a feature not found on the other two firmware versions. The averaging/sampling capabilitiesof Version 3 are the same as Version 1.



Channel Tagging

As discussed in the previous section, all current versions of the FPGA firmware are vulnerable in thecase that a piece of data is lost without this loss being detected. The beta version of the FPGAfirmware compensates for this by tagging one specific channel (user programmable) with a flag. Whendata is assigned to channels, this flag can be used to check that misalignment of data is not occurring.

Trigger Register

The channel to be tagged is set in the Trigger Register (see Section 2.2), which is modified as shownin Table 4. All settings used in other firmware versions are the same, but the 4 most significant bitsin the register, that were previously unused, are now used to store the channel number that the userwishes to be tagged. A sensible suggestion would seem to always tag the lowest channel number inuse, corresponding to the first column in an ASCII formatted data file. Note that the channel numberstored in the register must use the 0 - 15 numbering scheme.

bit 0 = 0 → 1 → 0 internal trigger command

bit 1 = 0 internal triggerbit 1 = 1 external trigger

bit 2 = 0 burst modebit 2 = 1 continuous mode

bit 3 = 0 real data modebit 3 = 1 simulated data mode

bits 7-4 = channel number to be tagged (numbered 0 - 15)

5 RESOURCES 29

Figure 11: Bitwise makeup of metadata in firmware version 3

Error meta-data

The error meta-data output from firmware versions 1 and 2 uses 4 possible states of the top two bits ofthe ADC’s 16 bit output. Version 3 uses one of these states to tag a marked channel, so the meta-datahas to be reorganised to accommodate this. firmware version 3 uses meta-data shown in Figure 11.It still has an error counter overflow bit, and gives the channel number of the last piece of data lost(NOTE: channels are numbered 0-15, and the channel given in meta-data is the last to be lost. If thechannel given in meta-data is 7 (”0111b”) then the first channel received after an error will be channel8).

The error counter has been reduced to 34 bit to accommodate the changes, though this still allowsfor over 17 billion pieces of lost data to be tracked. Presumably if this much data is lost the usefulnessof the remaining data is rather questionable anyway.

Diagnostics

The digital converter on the ADC board has 14 bit precision, but the board itself outputs 16 bits foreach data point. As discussed in Section 2.3

5.2 Uploading Firmware

This section will explain how to upload existing firmware to the FPGA. It will not explain how togenerate new firmware from source code. This information is available in the Xilinx ISE manual.

1. Connect the JTAG cable to the FPGA

There are two JTAG connections on the ADC board, labelled “RAM JTAG” and “XILINX JTAG”.The relevant connection is the “XILINX JTAG”.

The connections to the cables are as follows, with cable labels on the left and ADC board pinlabels on the right:

RST (purple) → TMSPROG (orange) → TDIDIN (green) → TDO

CCLK (yellow) → TCK

5 RESOURCES 30

Figure 12: Double Click “Boundary Scan”

GND (black) → GNDVCC (red) → VCCO(3V3)

The other two cables INIT (white) and D/P (blue) are not used.

2. Open iMPACT

Open the Xilinx iMPACT software, in Start → Programs → Xilinx ISE Design Suite 10.1 → ISE →accessories → iMPACT.

When iMPACT loads, close the prompt to open a saved project.Double click “Boundary Scan” in the pane on the left of the iMPACT window (Figure 12).Having double clicked “Boundary Scan” a prompt should appear in the main pane - ‘Right click

to Add Device or Initialize JTAG chain’.Right click in this pane, and select “Initialize Chain” (Figure 13).

3. Assign Configuration Files

iMPACT will prompt you to assign a configuration file. Select adcusb version x.bit (where x representsthe version number) in the directory “C:\FPGA Summer2008\Programming Files”.

iMPACT will now propt you to assign another configuration file. This is the file to load toPROM on the ADC board. when the board is powered down, when it is switched back on it willrevert to whatever firmware is saved in the PROM. Select adcusb version x PROM.mcs where againx represents the firmware version number you wish to load. The PROM files are also located in“C:\FPGA Summer2008\Programming Files”.

At this point, a Device Programming Properties window will appear. The default setting willprobably be correct, but should match the setting shown in Figure 14 and Figure 15.

Click OK to Proceed.

5 RESOURCES 31

Figure 13: Right Click and select “Initialize Chain”

Figure 14: Device Programming Properties for “Device 1 (FPGA, xc3s400)

5 RESOURCES 32

Figure 15: Device Programming Properties for “Device 2 (PROM, xcf04s)

4. Program Devices

Two device icons will appear in the main window, representing the FPGA and the PROM. Right clickeach icon and select “Program” (Figure 16).

The FPGA and PROM will now be programmed with the files selected earlier. After each hasbeen programmed a prominent “Program Succeeded” message is displayed. Note that programmingthe PROM takes significantly longer than programming the FPGA, though neither process shouldtake longer than about 20 seconds.

The ADC is now programmed with the new firmware and ready to be used.

5.3 USB Firmware versions

There are two directories containing versions of the USB firmware in location “C:\FPGA Summer2008\Source Code\Cypress”A folder labelled “Latest Serial” contains the latest code (including a hex file) with all current

commands valid. NOTE: The stop command needs to hold the dedicated stop line high for 20 x50MHz clock cycles to be effective. At the moment I don’t think it does, and a delay may needbuilding in. (The stop function is not hugely useful at the moment since the acquisition software hasno way of stoping a continuous run without crashing)

A folder labelled“Original Parallel” contains a near-original copy of the USB firmware code, COM-PATIBLE ONLY WITH OLD PARALLEL INTERFACE FPGA FIRMWARE. This firmware shouldwork with original ADC firmware, but has functionality for continuous/burst mode commands.

5.4 Other Documentation

Other Documentation includes circuit diagrams, software and hardware manuals.This can be found in directory “C:\FPGA Summer2008\Documentation” along with the source

code for this document.

A FPGA INPUTS & OUTPUTS 33

Figure 16: Right Click each icon and select “Program”

A FPGA Inputs & Outputs

The following comprises a list and simple description of some of the main FPGA inputs and out-puts, and whilst being far from comprehensive, may be helpful for anyone who wishes to make anymodifications to the FPGA and doesn’t want to wade through the LiCAS ADC circuit diagrams.

Communication Lines

MOSI Input “Master Out Slave In” line. FPGA serial data input line.MISO Output “Master In Slave Out” line. This is the corresponding line where

status flags are sent in serial to the USB controller.SSEL Input “Slave Select”. Communication with FPGA can only take place

when the Slave Select line is high.SCLK Input “Slave Clock”. The Slave Clock controls the FPGA’s reading

from MOSI and writing to MISO. One pulse on SCLK is requiredto read/write each bit.

stop Input Dedicated stop line. When in continuous mode, taking the stopline to 1 will halt the ADC

pc(7:3) Input Obsolete parallel communication bus (internal pc signal carriesregister address information)

pe(7:0) Input Obsolete parallel communication bus (internal pe signal carriesregister value information)

Control Lines

wen Output External FIFO write enable (active low)ren Output External FIFO read enable (active low)wen sdram Output RAM write enable signal (active low (CHECK))ren sdram Output RAM read enable signal (active low (CHECK))

B FPGA CODE 34

lvds trigp Input External trigger positive inputlvds trign Input External trigger negative input

Data Buses

sdolong(3:0) Input Input from ADC - Channels 4 - 0sdoshort(11:0) Input Input from ADC - Channels 15 - 5d(17:0) Output Data bus from FPGA to external FIFO (top 4 bits channel num-

ber, bottom 14 bits data)fifo(17:0) Input Bus carrying data back from External FIFOdata in(15:0) Output Data bus to RAM (data in bottom 14 bits, top 2 bits error

information)data out Input Data bus from RAM (data in bottom 14 bits, top 2 bits error

information)dout int(15:0) Output Final data bus carrying data and error information to USB. Also

sometimes refered to as “USB in”

Flags

ff Input External FIFO full flag (active low)ef Input External FIFO empty flag (active low)empty Input USB buffer empty flag (active low)full Input USB buffer full flag (active low)sdram empty Input RAM empty flag (active high)sdram ff Input RAM full flag (active high)

LEDs

idle Output Displays state of external FIFO full flag (LED on = full)DAQ Output Displays state of external FIFO empty flag (LED on = empty)hex(3:0) Input Controls the output conditions on the LEDs.

B FPGA Code

B.1 Rogue Data Point

Whenever a data acquisition run was started, and data output to a file, the first data point wouldalways be incorrect, seemingly from another set of data. All expected data was received as well, butit was preceded by two bytes that needed to be ignored.

The ADC was set up such that the write enable signal for the USB chip was the same signal asthe read enable for the FIFO that feeds the USB. It seemed that the USB was reading a piece of databefore the FIFO had time to put the first real piece of data on the data bus. The problem was fixed(though the fix has not been properly tested) by delaying the USB write enable signal to block thefirst enable pulse in any run. This was simply done by editing the process usb out2 as follows.

Original code:

usb_out2: PROCESS (rd_en_usbb, usbclk)

BEGIN

IF (usbclk’EVENT AND usbclk=’1’) THEN

IF (rd_en_usbb = ’1’) THEN //rd_en_usb = 1 means the internal FIFO is reading out

B FPGA CODE 35

slwr_int <= ’1’; //slwr_int = 1 means USB is writing

ELSE

slwr_int <= ’0’;

END IF;

END IF;

END PROCESS usb_out2;

New code:

usb_out2: PROCESS (rd_en_usbb, usbclk, reset_int)

VARIABLE delay : integer;

BEGIN

IF (reset_int = ’0’) THEN //reset_int = 0 is reset signal

delay := 1;

ELSIF (usbclk’EVENT AND usbclk=’1’) THEN

IF (rd_en_usbb = ’1’) THEN //rd_en_usb = 1 means the internal FIFO is reading out

IF (delay = 0) THEN

slwr_int <= ’1’; //slwr_int = 1 means USB is writing

ELSE

delay := delay -1;

END IF;

ELSE

slwr_int <= ’0’;

END IF;

END IF;

END PROCESS usb_out2;

B.2 SPI bus

library IEEE;

use IEEE.STD_LOGIC_1164.ALL;

use IEEE.STD_LOGIC_ARITH.ALL;

use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating

---- any Xilinx primitives in this code.

--library UNISIM;

--use UNISIM.VComponents.all;

entity SPI_BUS is

Port ( SCK : in STD_LOGIC;

MOSI : in STD_LOGIC;

MISO : out STD_LOGIC;

SSEL : in STD_LOGIC;

reset : in STD_LOGIC;

parallel_out: out STD_LOGIC_VECTOR (15 downto 0);

flags : in STD_LOGIC_VECTOR (7 downto 0)

);

end SPI_BUS;

B FPGA CODE 36

architecture Behavioural of SPI_BUS is

SIGNAL flag_reg : std_logic_vector (7 downto 0);

begin

-- Collect data to be sent

update_reg : process (flags, reset)

begin

if (reset = ’0’) then

flag_reg(7 downto 0) <= "00000000";

else

-- Flag registry shows all flags that have had value 1 since reset

flag_reg <= flag_reg OR flags;

end if;

end process update_reg;

-- Function to transmit registry contents when signaled

communicate : process (SCK, reset, SSEL)

variable counter : integer range 17 downto 0;

begin

if (reset = ’0’) then -- asynchronous reset

counter := 0;

parallel_out(7) <= ’0’;

elsif (SSEL = ’1’) then

IF (SCK’EVENT and SCK = ’1’) then

if (counter < 8) then

parallel_out(counter) <= MOSI;

MISO <= flags(counter);

elsif (counter < 16) then

parallel_out(counter) <= MOSI;

B FPGA CODE 37

MISO <= flag_reg(counter-8);

elsif (counter = 16) then

parallel_out(7) <= ’1’; -- set registry write strobe

elsif (counter = 17) then

parallel_out(7) <= ’0’; -- reset registry write strobe

end if;

counter := counter + 1;

end if;

ELSIF (SSEL = ’0’) then

-- reset counter and registry strobe when incoming data stream ends

counter := 0;

parallel_out(7) <=’0’;

END IF;

end process communicate;

end Behavioural;

B FPGA CODE 38

B.3 fake data

library IEEE;




-- When activated, this component will produce a sawtooth test pattern on each channel.

-- The pattern is a count up from an initial value, with each channel having a different starting value

-- The starting value of channel 0 is set below "chan0_start_val" and is a 14bit vector

-- All other channels have an initial value equal to

--chan0_start_val + (a*separation_val)

-- where a is the channel number.

entity fake_data is

generic (

-- initial value of channel 0.

chan0_start_val : std_logic_vector(13 downto 0) := "00000000000000";

-- difference between initial values of neighbouring channels

separation_val : integer := 1

);

Port ( clock : in STD_LOGIC;

sim_adcconv : in STD_LOGIC;


fake_sdoshort : out STD_LOGIC_VECTOR(11 downto 0);

fake_sdolong : out STD_LOGIC_VECTOR(3 downto 0)

);

end fake_data;

------------------------------------------------------------------------------------

architecture fsm of fake_data is

TYPE STATE_TYPE IS (

wait_for_strobe,

waiting,

serial_out

);

-- state vector declaration

ATTRIBUTE state_vector : string;

ATTRIBUTE state_vector of FSM : ARCHITECTURE IS "current_state";

-- Declare current and next state signals

SIGNAL current_state : STATE_TYPE;

SIGNAL next_state : STATE_TYPE;

-- Declare internal signals

SIGNAL fakedata0 : STD_LOGIC_VECTOR(13 downto 0);

B FPGA CODE 39
















SIGNAL bit_counter : integer range 14 downto 0;

SIGNAL wait_counter : integer range 2 downto 0;

---------------------------------------------------

BEGIN

update_proc : PROCESS(next_state, reset)

BEGIN

IF (reset = ’0’) THEN

current_state <= wait_for_strobe;

ELSE current_state <= next_state;

END IF;

END PROCESS update_proc;

---------------------------------------------------------------------

nextstate_proc : PROCESS(clock)

BEGIN

IF (clock’EVENT and clock = ’1’) THEN

CASE current_state is

WHEN wait_for_strobe =>

IF (sim_adcconv = ’1’) THEN

next_state <= waiting;

ELSE next_state <= wait_for_strobe;

END IF;

WHEN waiting =>

IF (wait_counter = 0) THEN

next_state <= serial_out;

ELSE next_state <= waiting;

END IF;

WHEN serial_out =>

IF (bit_counter = 0) THEN

next_state <= wait_for_strobe;

ELSE next_state <= serial_out;

B FPGA CODE 40

END IF;

END CASE;

END IF;

END PROCESS nextstate_proc;

------------------------------------------------------------------

counter_proc : PROCESS (clock, reset)

BEGIN


bit_counter <= 13;

wait_counter <= 1;

ELSIF (clock’EVENT and clock = ’1’) THEN


WHEN waiting =>

wait_counter <= wait_counter -1;

bit_counter <= 13;

WHEN serial_out =>

bit_counter <= bit_counter - 1;

wait_counter <= 1;

WHEN OTHERS =>

NULL;

END CASE;

END IF;

END PROCESS counter_proc;

-------------------------------------------------------------------

output_proc : PROCESS (clock)-- PROCESS(bit_counter, current_state)

BEGIN


WHEN serial_out =>

IF (bit_counter >= 0) THEN

fake_sdolong(0) <= fakedata0(bit_counter);




fake_sdoshort(0) <= fakedata4(bit_counter);












END IF;

WHEN OTHERS =>

B FPGA CODE 41

fake_sdolong(0) <= ’0’;




fake_sdoshort(0) <= ’0’;












END CASE;

END PROCESS output_proc;

-------------------------------------------------------------------

increment_proc : PROCESS(clock, reset) --PROCESS(current_state, reset)

VARIABLE increment : std_logic;

BEGIN


fakedata0 <= chan0_start_val; -- set initial values

fakedata1 <= chan0_start_val+separation_val;

fakedata2 <= chan0_start_val+(2*separation_val);














increment := ’0’;

ELSIF(clock’EVENT and clock = ’1’) THEN


WHEN waiting =>

IF (increment = ’1’) THEN

fakedata0 <= fakedata0+1; -- increment simulated data for each channel by 1

fakedata1 <= fakedata1+1;



B FPGA CODE 42














END IF;

WHEN serial_out =>


WHEN OTHERS =>

NULL;

END CASE;

END IF;

END PROCESS increment_proc;

END fsm;

B FPGA CODE 43

B.4 Diagnostics

library IEEE;




---- Uncomment the following library declaration if instantiating

---- any Xilinx primitives in this code.

--library UNISIM;

--use UNISIM.VComponents.all;

entity Diagnostics is

Port ( data_in : in STD_LOGIC_VECTOR (17 downto 0);

fifo_ff : in STD_LOGIC;


data_clk : in STD_LOGIC;

load_fifo : in STD_LOGIC;

output : out STD_LOGIC_VECTOR (17 downto 0);

wen_overide : out STD_LOGIC);

end Diagnostics;

architecture fsm of Diagnostics is

TYPE STATE_TYPE IS (

ok,

counting,

info1,

info2,

info3

);

--state vector declaration

ATTRIBUTE state_vector : string;

ATTRIBUTE state_vector OF fsm : ARCHITECTURE IS "current_state";

-- Declare current and next state signals

SIGNAL current_state : STATE_TYPE;

SIGNAL next_state : STATE_TYPE;

--Declare any pre-registered internal signals

SIGNAL counter : std_logic_vector (36 downto 0);

SIGNAL overflow: std_logic;

BEGIN

----------------------------------------------------

current_state_proc : PROCESS(reset, next_state)

BEGIN


B FPGA CODE 44

current_state <= ok;

ELSIF(reset = ’1’) THEN

current_state <= next_state;

END IF;

END PROCESS current_state_proc;

-- Output process - sets output signal based on current state. Note only bottom

-- 16 bits of output are sent over USB

output_proc : PROCESS (data_in, current_state)

BEGIN

CASE current_state IS

WHEN ok =>

output <= "0000" & data_in(13 downto 0);

WHEN info1 =>

output <= "0001" & overflow & counter(36 downto 24);

WHEN info2 =>

output <= "0010" & counter(23 downto 10);

WHEN info3 =>

output <= "0011" & counter(9 downto 0) & data_in(17 downto 14);

-- lowest 4 bits give channel number currently being lost, allowing realignment of

-- following data to correct channel columns by acquisition software

WHEN OTHERS =>

NULL;

END CASE;

END PROCESS output_proc;

--Next State Process - Defines conditional requirements for state transitions

nextstate_proc : PROCESS (data_clk, reset, current_state)

VARIABLE initial_delay : integer range 500 downto 0;

VARIABLE wait_b4_ok : integer range 100 downto 0;

BEGIN


next_state <= ok;

wait_b4_ok := 50;

wen_overide <= ’0’; -- wen_overide holds write enable off when high, to allow FIFO to recover

ELSIF (data_clk’EVENT and data_clk = ’1’) THEN


WHEN ok =>

if (fifo_ff = ’0’) then --FIFO is full - full flag active low!!

wen_overide <= ’1’;

wait_b4_ok := 50; -- Set delay

next_state <= counting;

else

next_state <= ok;

end if;

WHEN counting =>

B FPGA CODE 45

if (fifo_ff = ’1’) then -- FIFO no longer full

if (wait_b4_ok = 0) then -- wait fixed delay

wen_overide <= ’0’;

next_state <= info1;

else

wait_b4_ok := wait_b4_ok - 1;

next_state <= counting;

end if;

else

next_state <= counting; -- FIFO still full

end if;

WHEN info1 =>

if (load_fifo = ’1’) then -- load signal active high (It is not FIFO wen)


end if;

WHEN info2 =>

if (load_fifo = ’1’) then


end if;

WHEN info3 =>

if (load_fifo = ’1’) then

next_state <= ok;

end if;

END CASE;

END IF;

END PROCESS nextstate_proc;

-- Count Process - increments counter on each write enabled clock pulse to count number of lost pieces of data

count_proc : PROCESS (data_clk, reset)

BEGIN


counter <= "0000000000000000000000000000000000100";

overflow <= ’0’;

ELSIF (data_clk’EVENT and data_clk = ’1’) THEN -- count on enabled write pulses


WHEN counting =>

IF (load_fifo = ’1’) THEN

counter <= counter + 1;

END IF;

IF (counter = "11111111111111111111111111111111111") THEN -- set overflow bit


END IF;

WHEN ok =>

-- Offset required to output correct number of missing pieces of data.

-- Includes offset to compensate for 1st lost data piece/state machine change timing lag

-- Also includes data lost whilst error information is being sent.

counter <= "0000000000000000000000000000000000100";


WHEN OTHERS =>

NULL;

END CASE;

END IF;

C CYPRESS USB CODE 46

END PROCESS count_proc;

end fsm;

C Cypress USB Code

C.1 store data function

void store_data (unsigned char reg_add, unsigned char reg_data)

{

// Keep track of registers -- necessary for bit_set function

reg[reg_add] = reg_data;

//convert reg_add and reg_data into single bit stream

for(i=0; i<8; i++)

{

reg_bits[i] = (reg_add & (int)(pow(2,i))) >> i;

reg_bits[i+8] = (reg_data & (int)(pow(2,i))) >> i;

}

// Activate SPI

SCLK = 0;

SSEL = 1;

//send bitstream down serial bus, pulsing SCLK to write each bit

for(i=0; i<16; i++)

{

MOSI = (reg_bits[i]); // Send bit to FPGA

SCLK = 1; // Pulse to write and trigger return bit

SCLK = 0;

}

// Two further SCLK pulses to set and reset strobe

SCLK = 1; SCLK = 0;

SCLK = 1; SCLK = 0;

// Deactivate SPI

SSEL = 0;


// Pause to allow FPGA to reset SPI bit counter (probably unneccesary)

SYNCDELAY;

}

C.2 receive only function

void receive_only ()

{

EP1INCFG = 0xA0; // Configure EP1 for Bulk Transfer to host

EP1INBC = 0; // Set Byte count to zero

for(i=0; i<64; i++)

{

EP1INBUF[i] = 0; // Clear buffer

}

// No registers altered, so no reg[reg_add] = reg_data is required

// Activate SPI

SCLK = 0;

SSEL = 1;

//send bitstream "0000 0000 0000 0000" down serial bus, pulsing SCLK to write each bit

for(i=0; i<16; i++)

{

MOSI = 0; // Send bit to FPGA

SCLK = 1; // Pulse to write and trigger return bit

SCLK = 0;

FPGA_out[i] = MISO; // Receive bit from FPGA

}

for(k=0; k<2; k++)

{

data_to_ep = 0;

for(i=0; i<(8); i++) //Convert each string of 8 bits into 1 byte

{

data_to_ep = data_to_ep | ((int)pow(2,i)*FPGA_out[i]);

}

EP1INBUF[k] = data_to_ep; // Write byte to EP buffer.

}

EP1INBC = 2; // Set byte count to 2 to arm endpoint for data transfer

// No further clock pulses to cause FPGA to write to registry, instead take SSEL back to 0

// Deactivate SPI


SSEL = 0;

// Pause to allow FPGA to reset SPI bit counter (probably unneccesary)

SYNCDELAY;

}

Documents

MONALISA ADC/FPGA Documentation - University of Oxfordmonalisa/open/pages/projects/SummerProjects... · Figure 2: Burst mode data path through FPGA, with FPGA data inputs and outputs