FPGA: interleaved dma fifo "shuffles" inputs

[wiebe@CARYA]

---

@deceased wrote:

I too have joined number into 64bit for sending along the DMA, but the bus is (or was) physically only 32 bits wide, so it automagically splits the number up for you and does the 2 DMA writes behind the scenes.

---

But from a user's perspective it's a U64. The flush or timeout won't cause the items to get messed up, AFAIK.

[deceased]

---

wiebe@CARYA wrote:

---

@deceased wrote:

I too have joined number into 64bit for sending along the DMA, but the bus is (or was) physically only 32 bits wide, so it automagically splits the number up for you and does the 2 DMA writes behind the scenes.

---

But from a user's perspective it's a U64. The flush or timeout won't cause the items to get messed up, AFAIK.

---

I would assume the same

[chrissheffuni]

Hello, 

I have been having the same problem and stumbled on the solution by accident. How do you shut your host loop down? In my frustration I was using the red abort button which caused the 12345 to become 34512 etc. Anyway I asked my colleague to have a look at the problem and he noticed the abort button usage and then I used the stop button on the while loop. A miracle occurred and the close FPGA ref vi executed outside the loop and on restart my data set was 12345 12345 and has stayed that way. Data type was FXP as in the example vi in help for C RIO and NI9205 set up the same. Now after many years of programming in LabVIEW and being very well aware of the abort button and its dangers I didn't take my own advice. 

"If it doesn't work, try doing it the way you were taught" is in my mind at the time of writing. 

[wiebe@CARYA]

---

@chrissheffuni wrote:

I have been having the same problem and stumbled on the solution by accident. How do you shut your host loop down? In my frustration I was using the red abort button which caused the 12345 to become 34512 etc. Anyway I asked my colleague to have a look at the problem and he noticed the abort button usage and then I used the stop button on the while loop. A miracle occurred and the close FPGA ref vi executed outside the loop and on restart my data set was 12345 12345 and has stayed that way. Data type was FXP as in the example vi in help for C RIO and NI9205 set up the same. Now after many years of programming in LabVIEW and being very well aware of the abort button and its dangers I didn't take my own advice. 

"If it doesn't work, try doing it the way you were taught" is in my mind at the time of writing. 

---

An application shouldn't rely on the abort button, but I do want to use it during development without things blowing up.

I'd probably work on it until I could safely use the abort button...

The FPGA could conditionally put items on the FIFO. The host sets a Boolean to false, the FPGA stops fifo-ing, host (and\or FPGA) flushes the FIFO and sets the Boolean to true starting FIFO-ing. Your data should re-aligned after this sequence. It adds a regulated start\stop feature as a bonus.

Another option is to label the items. For instance, send U64s with flattened values, but reserve 1 byte for an item index. Obviously that only works if the data and one byte fit in the U64. This allowed re-aligning even after FIFO overflows.

[rolfk]

---

@deceased wrote:

I believe the DMA FIFO channels are 32 bits wide, unless this has changed on more recent targets.

If you have 2 16 bit values, in terms of performance, its best to bit pack them into a single 32 bit number.p Yeah 

---

---

Actually all data in a FIFO channel is always packed and aligned to 64-bit. And that is pretty much as long as NI-RIO exists.

[chrissheffuni]

I think I managed to make it work even using the self destruct button mentioned previously. I read the FIFO before going into the loop. I also set the timeout to -1 (I noticed the loop on the target doesn't iterate with this value timeout so no data can be placed in the FIFO?) Then once in the loop set the timeout to 0 then read the FIFO ….Start stop start stop abort start abort again etc and the data array remains 123412. Not very scientific but It does seem to work.