FPGA SPI communication inside a SCTL (single cycle time loop)

[patufet_99]

I'm trying to read the data from a 16 bit ADC converter through SPI with an sbRIO-9651.

Reading the data with a normal loop on the FPGA works as expected but the achieved speed is not very high.

I've tried to do the same by using a SCTL with a case structure where each case of the structure should not take more than a single tick to execute.

By looking with the oscilloscope the pulses generated and read seem to be OK.

The read conversion data seems, however, to be missing the MSB.

When reading for instance a voltage over the ADC range, I read 0011111111111111 instead of the expected 01111111111111111 (the ADC sends the data on two's complement).

I am missing something?

Any hints would be welcome!

[Rolf Kalbermatter]

Something looks odd in that timing diagram. As you are the SPI master you should generate the CNVST and SCLK signal, right? And then you should be starting to generate the clock signal after the  SAR Conversion time, which is depending on your chip and XCLK or similar. The first upgoing (or falling) edge of SCLK should cause the ADC to output the first bit of data, and you should then sample the SDO input in your FPGA on the other edge to make sure you read a steady state and not some transient. What you show is that you expect the ADC to start streaming the data on its own and then you start generating the clock, but that can't work.

This is the typical timing for a ADS8528 chip. I chose to have the CONV pin active high for the entire duration of what the worst case SAR processing time is supposed to be based on the XCLK that is separately provided to the ADC. But it is not important for this chip as it starts the SAR operation on the rising edge of this signal and expects CONV to be low before the /FS is activated but will not care about when the CONV pin goes low between those two moments.

The falling edge of the /FS pin (SPI chip select) starts the data cycle and on the falling time of the SCLK, also generated from the FPGA, I sample the SDO pin. The rising edge of the SCLK will signal to the ADC to output the next data bit. There are variations such as not each chip may use the /FS signal (or it might always be activated). But the principle is the same, activate the CONV to initiate a SAR, then wait for at least the worst case time the SAR will take and then start clocking the data bits. But you as master must clock these they won't just appear magically.

 

 

[patufet_99]

Thank a lot for you for your comment.

The truth is that I'm not really familiar with the SPI protocol. But as I understand from the datasheet after that the CNVST has gone low and after 10 ns you can read the first bit. At each SCLK rising edge it then changes the output to the next bit and so on.

The reading on the oscilloscope seem to confirm that the ADC works in this way. In any case what I see in the oscilloscope it's not what I'm reading out from the FPGA. So I was wondering if there is something wrong in my code.

The ADC is a MAX11901: the datasheet, contains several mistakes and it's not really clear.

MAXIM_MAX11901.pdf

Edited September 28, 2022 by patufet_99

[Rolf Kalbermatter]

Take a look at Figure 10 in the datasheet. What you see there is that the positive edge of CNVST starts the SAR. The DOUT then goes after a certain amount of time (t12) that is needed for the SAR to low. This indicates the readiness of the data on DOUT. After a time (t3) the first MSB is output (and could be a low too). You then need to sample the DOUT and after you read it you can immediately assert SCLK. The positive edge of this indicates to the ADC that you have read the data and it can output the next data bit. Then you deassert the SCLK signal after (t4). The data bit is not later than (t4) after the falling edge available. You can then read this and assert the SCLK again but not faster than (t8) after te falling edge of SCLK.

So the general sequence looks like this

1 ) assert CNVST and deassert SCLK

2) dassert CNVST not faster than (t11) = 20 ns later

3) wait for DOUT to go low (this takes time as in this time the SAR is ongoing, this is not 10 ns but at most t12 = 525 ns, but since you are waiting for this you have to wait at least as much, but more safe is simply to wait until DOUT goes low

4) wait at least 10 ns more after DOUT got low.

5) Read DOUT, this is your first bit

6) Assert SCLK

7) wait at least 4.5 ns

8 ) deassert SCLK

9) Read DOUT, this is your next bit

10) wait at least another 4.5 ns 

11) Go back to 6) until you have read all your bits.

The timing is only critical in terms of not going faster than the times mentioned here. You can certainly wait longer if your FPGA loop timing makes this more convenient. The 4.5 ns high and low time for the SCLK is a minimum, but of you don't go to the maximum sample rate (determined by the CNVST frequency you can also clock out the data slower. You simply need to have enough time to clock out the data before you start the next CNVST.

Those 4.5 ns wait I would simply make whatever your single cycle loop time is. That can be 5 or more ns, with the default FPGA clock of 40 MHz this would be 25 ns. 

With such a SCL loop driven at 40 MHz your maximum sample frequency would be about 525 + 10 + 16 * 50 ns = 1335 ns ~ 750 kHz

Edited September 28, 2022 by Rolf Kalbermatter

[patufet_99]

The cycle that you describe does not differ from what I wrote. The reached frequency is about 700 kHz.

The strange thing, is that what I get on the FPGA does not match what I expect.

Applying a voltage on the ADC converter over the ADC range, I get the reading on the image below:

01111111111111111, corresponding the maximum reading in two's complemented.

The FPGA algorithm returns however 00111111111111111, which is half of what it should be.

[Rolf Kalbermatter]

Any chance that it is operating in bipolar mode? Then the MSB would be the sign bit!

Edited September 30, 2022 by Rolf Kalbermatter

[patufet_99]

By waiting before reading the digital input, seems to solve the problem. This reduces, however, the reading frequency.

My guess is that there is some propagation delay at the FPGA digital input.