From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Adding DRAM storage to all 32 channels of "Finite Acquisition Multiple Channels" on FPGA PXI-5752 adapter

I am trying to add DRAM storage to the  "Finite Acquisition Multiple Channels" example of PXI-5752 adapter with a PXI-7952R FPGA. I want to store samples from all 32 analog input channels on DRAM for the maximum amout of smpling time.

I am trying to adapt the approach given in this disucssion.

http://forums.ni.com/t5/LabVIEW/Adding-DRAM-storage-to-quot-Finite-Acquisition-Multiple-Channels/td-...

When I enable the DRAM banks on PXI-7952R FPGA I see that I can access them as 64-bit FIFOs. I use Join Numbers to join the samples from 4 analog input channels into one I64. I noticed that each DRAM bank has a Write_Data_Upper and a Write_Data_Lower method. So in one clock-cylce I can write two I64s to the each bank. For two memory banks that means I can write 4x I64s, 16 chnnels to the banks per clock cylce when I use the IO Module Clock (50 MHz).

 

How can I write all 32 channels in one clock cycle? Can I create a derived clock at twice the IO Module clock frequency?

 

Thank you!

0 Kudos
Message 1 of 10
(3,000 Views)

What version of labview are you using? I have some example code I can post for LV 2014.

0 Kudos
Message 2 of 10
(2,951 Views)

Yes, I am using LabVIEW 2014.

0 Kudos
Message 3 of 10
(2,937 Views)

My apologies, I actually misread your original post. The DRAM on the 7952 does not have enough throughput to accept samples from all 32 channels every iteration. 

 

On the 795x FPGA modules the DRAM controller runs at 100MHz and performs reads and writes in 64 bit increments to each bank. Since we have two banks on the 795x modules, this gives 2*64*100,000,000 /8 = 1.6GB/s of throughput.

 

If the 5752 ADC clock is running at 50MHz, and we are sampling from all 32 channels, and the CLIP places the 12 bits of data into an I16, this gives us 32*16*50,000,000 /8 = 3.2GB/s of data. Since the 12 bits of data are padded into an I16, we can do some bit packing to get us down to 2.4GB/s of data, but even after bit packing we are still well above the maxmimum throughput of the DRAM on the 795x.

 

You will either need to upgrade to a 796x which has 3.2GB/s of throughput on the DRAM, reduce the number of channels you are acquiring from simultaneously, or limit the length of your record to what you can fit in BRAM.

0 Kudos
Message 4 of 10
(2,919 Views)

I see. This spec 800MB/s transfer rate per DRAM bank is also noted in the specification sheet.

 

I was thinking of writing all the data to FIFOs in a SCTL of the I/O Module Clock. Then send the data to another SCTL that writes to the DRAM at at least twice the clock speed of the I/O Module Clock, but your calculations convince me that won't work.

 

Jens

0 Kudos
Message 5 of 10
(2,909 Views)

Another option is sampling at a lower rate. Without bit packing you would need to go down to the minimum 25MHz. With bit packing you could go as high as 33MHz and still stream all channels to DRAM.

 

1.6GB/s * 8bits/byte / ( 32 channels * 12 bits/channel ) = 33MHz

0 Kudos
Message 6 of 10
(2,903 Views)

The FPGA also has block RAM  1,728kbit. With bit packing that can store 1728000/12/32*1/(50*10^6) = 90 mus of sampling of all 32 channels. Do you think I can combine the block RAM and the DRAM i.e. store 16 channels on DRAM and 16 channels on block RAM for a 180 mus samplng time?

Will the bitpacking or transfer from I/O module clock SCTL to DRAM 100MHz SCTL use memory? Can that be done with flip-flop fifos and look-up tables?

Thanks!

0 Kudos
Message 7 of 10
(2,887 Views)

Do you think I can combine the block RAM and the DRAM i.e. store 16 channels on DRAM and 16 channels on block RAM for a 180 mus samplng time?


Sounds like it should work. You may not be able to use 100% of the BRAM for record acquisition if any other functions on the FPGA vi require a little block ram to function. I would plan on using something like 80% of the BRAM, then write the rest of your application. Then before you are finished with the design, try cranking up the depth of the FIFO that implemented using BRAM as far as it will go until you fail compilation. 


Will the bitpacking or transfer from I/O module clock SCTL to DRAM 100MHz SCTL use memory? Can that be done with flip-flop fifos and look-up tables?

Thanks!


The bit packing shouldn't require any BRAM. I'm not sure about the DRAM FIFO. The DRAM FIFO on the 7952 is implemented using a CLIP that invokes a memory controller that runs asynchronously (at 100MHz) to the rest of the diagram. Pushing information to and from that controller from whatever clock domain the read and write resides invokes some sort of FIFO, but I don't know if that FIFO is implemented using BRAM or fabric. My guess is fabric but I suppose you could try compiling a VI with just a DRAM FIFO on it and check the resources utilized. 

0 Kudos
Message 8 of 10
(2,876 Views)

Thanks for all the advice.

I'll try to implement the bipacking first. Do you have a bitpaking example? Are there any VIs I should be aware of other than "Rotate Left with Carry" and "Rotate Right with Carry"?

0 Kudos
Message 9 of 10
(2,854 Views)

There are some examples in the FlexRIO Instument Development Library that perform bitpacking from a FAM that uses a 12 bit ADC (the 5772 Acq Engine example).

 

However the example only demonstrates how to do this on the 796x targets which means they're packing the data into a 128bit construct since that is the data width that the DRAM on those targets accomodate. You'll be trying to pack the data into a U64 since that is the data width of the DRAM on the 795x targets.

 

Also I think the 5772 CLIP pads the LSB with zeros while the 575x CLIP pads the MSB bits with zeros...or vice versa. Anyway, you wouldn't be able drop the functions they've put together into your code. 

 

You can take a look if you want, but it will probably take you less time to roll your own than try to adapt any existing bit packers that I'm aware of. 

0 Kudos
Message 10 of 10
(2,841 Views)