LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA: Replace Block RAM with DRAM

Hi, 

 

I'm implementing an algorithm on a PCIe-7857. I need to be able to download a test signal to use instead of an analog input signal, for which I created a FIFO and a Memory Item. 

 

A Memory Item implemented by Block RAM is simple and works perfectly, but in my case uses ~70% of the FPGAs total available Block RAM, so this is no way to go. I want to implement it by DRAM instead. My timing requiremens are quite relaxed, I can wait up to 40 ticks (@40MHz) for data to be available. 

 

Writing to DRAM is easy enough, but I am having trouble reading the data. This was my first attempt:

wergor_1-1626686207861.png

The problem with this is that the first ~28 samples returned by the Retreive Data function are invalid (they are either 0 or some other part of the test signal). I tried other ways to do it like 

wergor_3-1626688266230.png

or 

wergor_4-1626688277162.png

where execution order is enforced by a wire, but none of those worked as intended - that is, to specify a read address and then read that exact sample from memory. 

 

 

TL;DR: I want to do this: 

wergor_2-1626688196112.png

using DRAM. How do I do it right?

0 Kudos
Message 1 of 4
(2,039 Views)

The timing of using the DRAM is going to work a bit different than the internal FPGA RAM so it is handled differently in LabView FPGA.

 

With internal FPGA memory, you can read data on every clock cycle with a known and fixed latency. It behaves in a consistent way and everything is synchronous. With internal memory, it makes sense to think about it as a single box: address goes in and for every address that goes in, data comes out.

 

Things become a bit more complicated when accessing the DDR which is a separate chip and likely asynchronous from your FPGA. Reading from DRAM is usually a multistep process and happens over several clock cycles instead of just one. Additionally, the timing of this is not consistent because the DRAM occasionally needs to be refreshed (which pauses anything else that might need to go on). The good news is that Labview handles all that extra DDR complexity for you but it does mean that it needs to be used in a slightly different way. Think of the "Request Data" block as putting a request to read from a particular address in a queue. When the DDR is ready and able to read from that address, it will put the requested data in the "Retrieve Data" queue where it will be waiting for you. The data in the "Retrieve Data" block appears in the same order that it is requested.

 

This example is probably a good template to get started: NI FlexRIO Basic DRAM Example - NI Community

Message 2 of 4
(1,936 Views)

There are DRAM IDL (VIs) which make this simpler.

 

NI's documentation on this is not the best but it does exist.  See https://forums.ni.com/t5/LabVIEW/Memory-IDL-documentation-FlexRIO-DRAM/td-p/3316961 (a post of mine from a while back) but it does lead you to some links on this.

 

Bottom line for me is once I took the time to learn to use the IDLs it was much easier than the primitives shown in your screen shots.

 

###

 

Didn't know about https://forums.ni.com/t5/Example-Code/NI-FlexRIO-Basic-DRAM-Example/ta-p/3500004.  That looks helpful if the primitives are going to be the route to be taken.


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
Message 3 of 4
(1,926 Views)

Unfortunately the DRAM IDLs are not available for the 7857. However, the basic DRAM example pointed me in the right direction. I just had to make sure the request for each address was issued exactly once, and data retrieval was only attempted after a request has been issued. 

In hindsight, the first is obvious, but I did not expect the retrieve data function to return TRUE on 'output valid' even tough there is no request for which data can be returned. 

 

Here's my solution:

read dram.png

 

For reference, this was the result when not waiting for a successful request before reading data (the graph should show a sine):

read_no_wait_code.png

read_no_wait.png

  

0 Kudos
Message 4 of 4
(1,877 Views)