Increment Contents of FPGA Block Memory

[Zetariah]

I am attempting to to perform sequential high-speed data acquisitions using LabVIEW FPGA. I would like to process the data on the FPGA and then record the number of similar events in block memory (basically a histogram), then transfer the data to the host after each sampling period is complete. The time between sampling periods must be small - a few ms. The desired block memory size is 65536 elements, each element being U64 bits.

I have done this using DMA FIFOs, but there is a real possibility of overrunning the FIFO due to exceptionally high data rates and long acquisition periods. Additionally, I would be forced to serially analyze each data element in the host (Windows), a process that proves to be far too slow. 

The real problem is having to increment (read and write) the data element in the block memory without conflicts related to simultaneous access. Even though I have configured the memory to never arbitrate, I get randomly corrupt data. I have found the following suggestion in many locations on the website (this is one example location):

http://zone.ni.com/reference/en-XX/help/372614J-01/lvfpgaconcepts/fpga_memory_items/

Of course, when using this design in a SCTL (as I do), one needs to include the the appropriate number of feedback nodes in the read method, depending on the block memory read latency selected. While I have implemented this basic design inside and outside a SCTL, I have yet to get it to function without data corruption (additional or missing events in a record).

I am trying to run this process at 50MHz (100Mhz top-level clock). My current development system is as follows:

• PXIe-1082 Chassis
• PXIe-8133 Controller
• PXIe-7820R DAQ Module
• 2016 LabVIEW Professional Development System
• 2016 LabVIEW FPGA

I have the distinct feeling that this is a simple, standard block memory action and I am just missing something exceptionally obvious. I have attached the FPGA VI and hope that someone has a reasonable suggestion (that won't make me feel too stupid). The latest version of the code of interest is the next-to-last SCTL (vertically arranged).

Thanks in advance!

Tony.

[jiangliang]

I have the question very much like yours.

If your using cIRO 9068, you might want take a look into "Host Memory Buffer". But I myself is new to this very recently, still try to figure out the property of this function.

[Zetariah]

thanks for the comment and suggestion, though I'm not using the cIRO 9068. I'm still working on this issue. I have created a small FPGA vi focused only on this data transfer problem and it seems to work well. When I insert it directly into my larger design exactly as it is, it does not function. I'm truly puzzled. I've attached the stand-alone FPGA vi in the hope that someone can identify the flaw . . .

[James_McN · Accepted solution]

Unfortunately I don't have a correct FPGA version installed to run through the whole application and understand it fully but I was able to take a quick look.

As you mentioned, you definitely need to match delay lines and you aren't everywhere at the minute. The obvious one is the address for the incrementing memory. The data lines are delayed by 2 (and maybe 2 more inside the memory block by the symbols) but the address line has no delays so this is probably the source of corruption.

I would also look at moving data between looks using small FIFOs rather than the local variables as this is dangerous with single-cycle loops. You certainly have one issue with the same piece of code as you have a delay in a conditional structure. This means the write won't happen two cycles later but two trigger signals later. You also have no validity check on the delayed data which will mean the first two runs you will write invalid data into the memory.

Your second example does not use single-cycle timed loops or delays which helps to avoid most of these issues. That is why it works better.

Take a look at handshaking on FPGA (http://zone.ni.com/reference/en-XX/help/371599F-01/lvfpgaconcepts/fpga_handshaking/) this is very important for these type of algorithms and should solve many of your problems.

Cheers,

James

[Zetariah]

@James_McN: Thanks for the excellent advice - just what I was looking for. I've solved the issues and all seems to be functioning as expected. The reference to the article on handshaking was particularly informative.