(3) p2p devices - start sequencing

[mstaylor97]

Is there any experience or guidance on startup timing / sequencing on 3 device peer to peer streaming.  I'm using a PXIe-1073 chassis where I want to set up the following data flow:
RFSA -> FLEXRIO1 -> FLEXRIO2 -> Host Display. 

The last link would of course be a DMA to the host, but the first (2) would be PXIe devices capable of P2P.  I haven't been able to find anything on FPGA configuration timing relative to when to try and connect the P2P links (ie is there some needed wait time for the bit file load/FPGA startup sequence before trying to run the P2P create/enable stream VI's), and in which order (If any) is preferred to bring them up in (ie consumers first followed by producers, or vice versa).  Couldn't find any NI documentation/examples relative to this scenario for guidance.

Any information is appreciated.

[David-A]

As soon as you have a reference to both of the targets that are streaming to one another, you should be able to configure a p2p stream. I'm also not sure what you mean by the order to bring them up in. You need a valid reference to both the consumer and producer to create a stream, so they would be 'brought up' at the same time. 

Have you taken a look at the Peer to Peer example that ships with the FlexRIO driver? If you open the example finder its located in Hadware Input and Output>>FlexRIO>>Peer to Peer.

[mstaylor97]

If I have 3 devices, there are two links, RFSA to FPGA1 would be link(1), FPGA1 to FPGA2 would be link(2), and of course there's the DMA back to the host from FPGA2, but that's different because it's not using the P2P API's, and I've dealt with the DMA flow control.  All of the included NI examples only involve 2 devices, you get a reference to the writer, a reference to the reader, then you enable the link.  In my case, FPGA1 is both a reader and a writer, with associated P2P FIFOs defined in the project (ie FPGA1 will have a P2P_reader FIFO, and a P2P_writer FIFO).  So when i'm questioning order of running the "enable_stream" VI, do I need to enable the link(2) stream first, or the link(1) stream first, or does the P2P API account for either? 

[David-A]

---

 So when i'm questioning order of running the "enable_stream" VI, do I need to enable the link(2) stream first, or the link(1) stream first, or does the P2P API account for either?      

---

Ahh, gotcha. I would recommend enabling the nodes furthest down stream first, then working your way back upstream. That way data doesn't start flowing downstream until the entire chain is ready.

Was there any particular issue you ran into or were you just curious if there was a best practice that addressed this scenario?

[mstaylor97]

---

Was there any particular issue you ran into or were you just curious if there was a best practice that addressed this scenario?

---

Both 🙂  I'm having crazy trouble getting both links up. Some of it I'm starting to get a handle on, but could still use some more information.

NI offers some property nodes for these P2P links, Writer overflow, reader underflow, but doesn't offer much in the way of explaining what to do when these instances occur, or exactly what's causing them. Elements available for read, elements available for write could be better explained as well.  I'm getting underflows and overflows on both links, so I'm just trying to whilttle away at possible issues.  Unfortunately I can't share our code, it's on an offline system and I don't have a way to get it off.  Bringing the links up from the consumer side makes sense though, I'll make sure that happens and go from there.  I'm adding some debug logic to the downstream FPGA, but (I don't know if I've mentioned) I don't have source code for the upstream side.  If you have any additional references on the P2P controls, ie, I sometimes see that even though I've ran the "create stream" VI with the default value (T) to enable stream, I sometimes see the link state be "disabled" in my monitoring loop.  I'm assuming this is due to some # of overflow/underflows reached, but information on what causes a link to disable itself would be beneficial.  I am monitoring the error wire from these property nodes while polling them in a loop with a 25ms wait timer inside (both links are monitored in the same loop after trying to bring everything up). 

I believe the upstream FPGA getting data out of the RFSA used an NI example to start from, as I see lots of similar setup in the main VI for the RFSA property nodes, but I can't change the size of their FPGA P2P read FIFO (only 1023) without code. We're trying to stream 40Msps I/Q from the RFSA, then 40Msps i16's from FPGA1 -> FPGA2, so it should be well within the bandwidth of the bus on the 1075. FPGA1 and FPGA2 are on the same PXIe switch (slots 10,11), while the RFSA occupies several slots down adjacent to the controller (8135), so the 5622 is on a different switch.

thanks for any info!

[David-A]

What version of labview are you using? If you're using 2014 there are a few libraries in the inst.lib folder that will help manage streams of data between endpoints. 

[mstaylor97]

I recently upgraded to 2014 SP1, I'll take a look in inst.lib and see what I can find.

[David-A]

The LabVIEW 2014\instr.lib\_niInstr\Streaming directory has the library that you'll be intrested in. 

You can see how the streaming library is used if you take a look at the getting started example for the 573x, or 576x.