ADC problem observed - CS to valid data time extremely high.
Brief Background:
When sampling at 200ksps, using two 8channel ADCs, the previous
conversion data has to be read out from the ADC during the subsequent
conversion, in order to achieve sufficient throughput for that sampling
rate. When retrieving data from the ADC in normal operation (i.e.
reading a result directly after the conversion), the ADC provides a flag
to indicate when the data for the first channel is placed on the bus.
However, when reading out data during a conversion this flag is not
raised. This should not be a problem as the data sheet indicates there
is a maximum time of 32ns from the RD (active low) going low to valid
data on the bus. The clock for the ADC core operates at 20Mhz with a
period of 50ns, therefore the ADC core should be able to latch data on
the clock cycle after lowering the CS and RD lines.
The problem:
When carrying out an acquisition it was observed, that all channels from
the 2nd ADC chip were returned as the same value. When investigating
this using chipscope it was found that no new data was being placed on
this bus when attempting to read out data from the 2nd ADC chip. As a
result the same data was being latched repeatedly and stored as separate
channels. This had been tested previously and had always been working
fully.
The problem was investigated using a different version of the ADC
controller which gives sample commands at 100ksps, allowing data to be
read out after a conversion has taken place. As a result the first
channel flag can be produced by the ADC and the state machine in the ADC
controller has the time to wait for this flag before taking the data.
It was observed that from the CS falling (active low), there was around 10uS before this flag was raised. The data sheet does not indicate any potential change of this time with temperature or any other conditions, and only mentions the maximum of 32ns. As can be seen on the waveform this delay causes the a sample to be missed, therefore reducing the sample rate. It can be seen at around 200samples (x -axis) that the signal 's_sample' produces a pulse, however the additional delay has meant that the state machine was not in the correct state to produce a pulse to the ADC (CONVST_o on the waveform).
When testing the board the following day this behavior had stopped and the ADC chip was working normally.*
Conditions when problem was observed:
During the time when this problem was observed there were wires soldered
to the board to observe the SPI signals to a DAC which provides a
reference to the VCXO. A further wire was soldered to the ground pin of
the regulator.
These wires had been removed when the board was tested the next day.
It seems unlikely that this was an error in the VHDL because different versions of the firmware were used, and the top level constraints file was edited to swap the pins for the CS lines, in order to establish if the chip was faulty or the problem originated from the ADC core controller. As expected the fault was observed to remain with the ADC chip.
Short term steps taken :
Mezzanine cards which are mounted with 2 x 6 Channel ADCs use the
version of the ADC controller which reads the data after a conversion.
This is due to the fact that 6 channel devices complete a conversion
more quickly than 8 channel devices and means that sufficient throughput
can be achieved in this ADC controller version. The same controller can
be used for cards with 2x8 Channel ADCs assuming the sampling rate is
set to 100ksps. Due to the fact that the state machine waits for a first
channel pulse before reading data, this version will be guaranteed to
only take valid data. Furthermore, a counter has been added to the main
firmware verson which counts samples which are missed. If a sample
request (s_sample signal pulse) is produced while the state machine is
not in the state which allows a sample command to be produced, the
counter incriments. This means that this particular error can be
detected with further testing.