LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview FPGA DRAM Address question

Solved!
Go to solution

The problem was never data corruption because of addressing.  This question was purely academic due to observed behavior not matching documentation.  

 

We finally worked around the issue by taking the DRAM out of the design.  To remove complexity (as our application allows it), we changed from random access mode to FIFO mode.  We still got issues (again, intermittently) - so we switched to a FIFO constructed completely out of block RAM (target-scoped FIFO).  Now the entire design functioned properly (never providing any incorrect data) but didn't grant us the storage we needed.  I replaced the write-interface to the target-scoped FIFO with a DMA-FIFO to the host, and the application now works flawlessly in a streaming form after eliminating the read-side of the DRAM interface.   

0 Kudos
Message 11 of 18
(3,811 Views)

I am glad that you are now up and running.  Good luck with your application!

 

Brandon Treece

Applications Engineer

National Instruments

0 Kudos
Message 12 of 18
(3,796 Views)

Hello All!

 

I hope the following information, along with the screenshot, provides further clarity to the infomation discussed in this forum post.

 

There are two ways to access the DRAM on your FlexRIO Device from LabVIEW FPGA. You can use the provided Socketed CLIP (Green) or the FPGA Memory Items (Yellow) (both can be seen in the project in the screenshot below). The DRAM that you are accessing is 128 bits wide which makes addressing it tricky when the largest LabVIEW Supported Datatype is 64 bits.

 

When accessing the DRAM from the CLIP, the CLIP gives you inputs for an Address along with upper and lower data groups. Each of those data groups is 64-bits and collectively amount to addresses 0, 1, 2, 3. So, to write 128bits of data continually to the DRAM, you increment the address by 4, as Brandon has covered in detail in previous posts.

 

When accessing the 128bit DRAM from the LabVIEW FPGA Memory Items, you are only given the option to write one data value, and because the largest FPGA datatype is 64 bits, you might think you need to address the DRAM 0, 2, 4, etc as to correctly address each 64 bit data. This is incorrect because the address doesn't actually adjust for the size of the DRAM memory item datatype. Instead, each address corresponds to the full width of the DRAM. When using the Memory Items, LabVIEW handles the actual physical addresses behind the scenes and you address your data 0,1,2,3, etc. This, however, does raise a good question. If each address corresponds to 128bits of data, and LabVIEW's biggest datatype is 64bits, how do you best utilize the full data width? You can have the DRAM's datatype be a custom control, and create a custom control containing a cluster with two U64 Data Types (seen in blue).

 

 

Addressing.png

 

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ben Sisney
FlexRIO V&V Engineer
National Instruments
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Message 13 of 18
(3,774 Views)

Does this mean I can write using the CLIP method using only the lower 32 bits of the lower U64 and increment the address by 1 each time to write subsequent 32-bit values?  Is it possible to use this to then read out a specific 32-bit value (Aside from extracting the lower 32 bits of the 64-bit "Lower" value).?

 

I'm only getting into DRAM with FPGA and it is mightily confusing.  I wanted to work with memory items but the "Enable" and "Ready" mishmash combined with some rather ambiguous help makes me want to cry.

 

I want to be able to use DRAM as a ring buffer for data acquisition for values which are 32 bits in size.

 

Shane.

 

PS What do the "Mask" inputs do?  Does this allow me to really only write 32 bits if I want to, leaving hte other 96 bytes of the 128-bit interface width intact?  Can I use this to create my own proper 32-bit memory interface?

0 Kudos
Message 14 of 18
(3,107 Views)

Hello Intaris,

 

It sounds like you want to use the FIFO implementation of the DRAM CLIP. It does need to run at 128 bits, so you'll have to do  bit-packing to make it work. However, it simpler and it automatically implements your circular buffer for you. The only downside is that you need to gather four 32-bit chunks of data together for every write and read. There's an example finder example for FIFO DRAM - go to Hardware Input and Output --> FlexRIO --> External Memory --> Simple External Memory FIFO.lvproj

 

It doesn't seem like this should be an issue though. DRAM is meant for large amounts of storage capacity. If you are planning on reading the first 32-bit number you are writing to your DRAM FIFO before you write your fourth 32-bit number, then the amount of space your DRAM FIFO needs to use is small, and you could easily implement the same functionality using a target-scoped FIFO of I32 or U32 numbers. If you don't need to read the 1st number you write before your write your fourth number, then you can just bit-pack the four 32-bit numbers together and unpack them on the read. 

 

The other option is to use a normal memory item in your project and choose the implementation to be in DRAM. Then you can choose an I32 or U32 as the data type. You may end up not utilizing memory space effectively. I'm not actually certain how effective the memory usage is when you choose I32 numbers.

Colden
0 Kudos
Message 15 of 18
(3,075 Views)

Nope, I don't want a FIFO, it needs to be randoma ccess.

 

My question is following:

 

if I set (Via CLIP) FF000000 to address 0, then the DRAM Memory looks like FF0000000000000000

 

If I then write AA000000 to Address 1, does the memorys then look like FFAA000000000000 or does it look like FF000000AA000000 ?

 

Shane.

0 Kudos
Message 16 of 18
(3,067 Views)
0 Kudos
Message 17 of 18
(3,038 Views)

Hey Intaris,

 

Sorry about the delay. I think response time on this is limited because the original forum is over a year old.

 

I don't have the hardware to test this out myself, so I would need to ask those who know more about the inner workings of the FPGA DRAM CLIP. But this is a fairly easy thing for you to test. If you set up a VI that reads from and writes to memory, you should be able to see what happens to the data if you write to address 1.

 

I know that the recommended way to use this CLIP is to increment the address by 4 each time. I'm not sure what exact functionality to expect if you use it outside of the recommended fashion.

Colden
0 Kudos
Message 18 of 18
(3,016 Views)