FMC ADC 200k 16b 11cha issueshttps://ohwr.org/project/fmc-adc-100k16b8cha/issues2019-02-12T09:04:35Zhttps://ohwr.org/project/fmc-adc-100k16b8cha/issues/2SPI master and AD5662BRMZ-1 DAC bug2019-02-12T09:04:35ZRoss MillarSPI master and AD5662BRMZ-1 DAC bugBug observed when setting the register in the AD5662BRMZ-1 DAC. Wires
were soldered to the board to observe the SPI lines with an
oscilloscope, and the waveform appeared as expected. When investigating
the problem it was found that setting the top data bit high (bit 15), of
the DAC data register (bits 15:0), a value was instead being written to
the part of the register which controls the mode of operation (bits
17:16). This would place the DAC into power down mode. This behaviour
seems dependand on the firmware version despite using the same SPI
master.
It is suggested that the SPI master is configured differently using the
clock polarity and clock phase fields in the control
register:
http://opencores.org/websvn,filedetails?repname=simple\_spi\&path=%2Fsimple\_spi%2Ftrunk%2Fdoc%2Fsimple\_spi.pdfhttps://ohwr.org/project/fmc-adc-100k16b8cha/issues/3ADC problem observed - CS to valid data time extremely high.2019-02-12T09:04:36ZRoss MillarADC 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.
### Files
* [ADC_problem.jpg](/uploads/10760c5179f5ef73993e121f068e164c/ADC_problem.jpg)https://ohwr.org/project/fmc-adc-100k16b8cha/issues/7Camera Link connector should touch front-panel, opening for screws2019-02-12T09:04:38ZErik van der BijCamera Link connector should touch front-panel, opening for screwsThe front-panel connector should touch the front-panel and have a small
cutout for the screws for the cable. The screws should be 'lifted' to
touch the front-panel at the outside of the FMC panel. Otherwise the
screws of the cable connector are not long enough to be screwed in.
Screw used: 3M 3341-31 (standard screw for 3M, the 3341-13 is special
and much more expensive). See
http://www.mmm.co.jp/electrical/connector/cable_assembri/pdf/camera_jack.pdf
At the bottom it reads:
- \-31J: “For Panel Mount (t = 1 ~ 2mm thick panel)”
- \-13 : “For single connector.”Ross MillarRoss Millarhttps://ohwr.org/project/fmc-adc-100k16b8cha/issues/9Schematics need clean-up and pass via design office2019-02-12T09:04:39ZErik van der BijSchematics need clean-up and pass via design officeThe schematics are not complete (no titles, page numbers etc.).
Also the design needs to be passed through the design office for
verification and correction.Ross MillarRoss Millarhttps://ohwr.org/project/fmc-adc-100k16b8cha/issues/11Propogation delay of buffer in feedback loop of PLL2019-02-12T09:04:40ZRoss MillarPropogation delay of buffer in feedback loop of PLLCurrent design contains an AND gate, used to buffer the signal from the
mezzanine clock to the carrier board to 2.5V.
This adds a 2ns propogation delay to the feedback loop. Needs to be
investigated to see if this will be problamatic for synchronisation of
the clocks on the carrier and mezzanine.
Perhaps not even required in the design as the IO bank on the FPGA is
powered by 2.5V however it can be driven by 3.3V, which is the output of
the VCXO before it has been buffered.