ADC problem observed - CS to valid data time extremely high.
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.
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.