How receive DDR data in LabVIEW FPGA?

[johnsnow34]

Hello everyone,

I want to use sbRIO 9651 to receive DDR output data from four channels of ADC(LTC2174). I'v tried to use data output clock(DCO) of ADC as SCTL clock for data receiving. But because of DDR, I can only receive the data on DCO rising edge, the data on falling edge will be lost.

According to another post, I'v also tried to use IDDR on FPGA to receive DDR data. It works fine for one channel, but when I instantiated IDDR in CLIP for more than one channel, there was a error report. It seems like I can't instantiate more IDDR. I am not familiar with VHDL.

Anyone have idea, what is the way to receive DDR data in LabVIEW FPGA?

[cbutcher]

Hopefully someone with familiarity with the CLIP or similar technologies can give a better answer, but as a simpler idea, you can program the FPGA at a lower level using just a state machine and SCTL.

The code I used to do this was driving the clock for a SPI interface (AD7608, LTC2983 - this one is slow, so not even SCTL), not receiving a clock from the device end, but it wasn't too complicated to do. If you check for the changing DCO input and then trigger reads on other lines based on that timing, you should be able to get both halves. I'm not sure what you've already done, so I can't really guess how much more work that might entail.

Does that help at all?

[johnsnow34]

Hi cbutcher,

see you again😃. 

---

If you check for the changing DCO input and then trigger reads on other lines based on that timing

---

I'm sorry. I don't understand what is the specific implementation steps. My DCO is 70Mhz. Could you please explain it in detail? Thank you.

[James_McN]

Hi John,

I can't give you a lot of detail but I think you do need to find a way to make the IDDR work.

If it was slower then you might be able to do it by bringing the clock in on a data line to LabVIEW FPGA however 70MHz will be too fast for that.

Unfortunately that is going to mean some VHDL. The CLIP node makes the most sense although you may be able to use an IP integratio node. Can you share the error you got and perhaps it may give some idea of what went wrong?

[cbutcher]

---

@johnsnow34 wrote:

Hi cbutcher,

see you again😃. 

---

If you check for the changing DCO input and then trigger reads on other lines based on that timing

---

I'm sorry. I don't understand what is the specific implementation steps. My DCO is 70Mhz. Could you please explain it in detail? Thank you.

---

My idea was a fairly straightforward (perhaps naive) idea, but I guess it won't work at 70MHz DCO based on James' comment. My clock rates are at most ~15MHz, which makes it more attainable.

Sorry for the misleading suggestion.

Spoiler

For reference, it's basically just manually reading/flipping bits on the SDI/SDO (or MISO/MOSI, if you prefer) along with the appropriate edge(s) of the SCLK signal. Having to measure the SCLK presumably introduces a need for oversampling, which will make it impractical (impossible?) for you. Even without that, you might struggle to get the cycle rate high enough to satisfy your needs (my FPGA runs its SCTL at the basic 40MHz rate).

[James_McN]

---

@cbutcher wrote:

---

Spoiler

Having to measure the SCLK presumably introduces a need for oversampling, which will make it impractical (impossible?) for you.

---

Yeah I probably should have been more specific. That would be my concern. I would think in most cases you would want to oversample by at least 4-10x (4 still only means 2 samples per level, so may still not be enough, probably want 3 to make sure you sample well before the centre point). This would mean running loops at > 200MHz which is generally difficult (and really you are looking at 280+ which is basically impossible)

[deceased]

I think on FlexRIO you can use an external clock as the timing source for a SCTL but not in other NI FPGA hardware.

As James has pointed out, oversampling looking for rising/falling edges is probably not going to cut it at the sampling rates you need.

I am wondering if its possible to connect the signal into 2 input pins on the FPGA (same with your ext clock) and use 2 loops, one for rising edges and one for falling, then recombine the data afterwards in some as yet undefined magic.

[deceased]

---

@deceased wrote:

I think on FlexRIO you can use an external clock as the timing source for a SCTL but not in other NI FPGA hardware.

As James has pointed out, oversampling looking for rising/falling edges is probably not going to cut it at the sampling rates you need.

I am wondering if its possible to connect the signal into 2 input pins on the FPGA (same with your ext clock) and use 2 loops, one for rising edges and one for falling, then recombine the data afterwards in some as yet undefined magic.

---

I was thinking about this again, and I don't think spitting the signal up will help.

Do you have a timing diagram showing when the data is valid on clock transitions?

[johnsnow34]

Hello,

I have solved this problem. IDDR will work fine for DDR data receive. I early used same IDDR instantiation name for multiple output in VHDL code, so I got the error. And the IDDR code should be add into CLIP. This post explained how to realize it.

Thanks for all your replies.

[MDemerse]

You may be experiencing something along the lines of what's mentioned in the last paragraph of this post: 

"Most FPGAs are designed with a global clock pin that will distribute the clock throughout the chip and other pins that will confine the clock to particular regions. Improper choice of a clock pin will create a system-level design issue that will allow the board to work most of the time, but not all of the time."