FlexRIO PXI_Trigger Unexpected Behavior

[JJMontante]

Good morning all,

I could use some help troubleshooting unexpected behavior when using PXI_TRIG lines to coordinate behavior between three FlexRIO cards (7971 with 6589 FAMs).  These FlexRIOs are configured as packet traffic generators, and when commanded, should send out a traffic packet. Individually, all FPGAs work as expected (generating traffic, SocketCLIP, host control etc) both in simulation and hardware.

Together, they fail to trigger.  The scheme is this:

1) Configure all FPGAs with the proper bitfile

2) Host calls "Invoke Method" and reserves PXI_TRIG for each FPGA.  Trig 5 for FPGA 1, Trig 6 for FPGA 2, and Trig 7 for FPGA 3.

3) Write configuration controls to each FPGA, so they know which PXI trigger lines they are responsible for.  This is handled with a case statement (See Figure 1).

4) Send a False-True-False sequence to controls on each FPGA to signal that the host loop is ready for each FPGA to generate traffic.  Each FPGA should send a pulse to its respective trigger line, allowing each FPGA to proceed in its state machine because each its neighbors have all reported readiness (this neighbor readiness is stored in a synchronous latch).

5) Sent a False-True-False sequence to controls on each FPGA to signal that the FPGAs should all send out a specific traffic packet.  This works similar to step 4, once all FPGAs have used their respective triggers to signal readiness to neighbor FPGAs, the packet is sent.

6) In practice, only one channel ever sends its packet.  THIS IS THE PROBLEM PHENOMENON.

I built a test FPGA to understand what the triggers were doing (Source is attached). It allows the user to individually set the Trigger Data Value and  and a host application that simply sets the controls/reads and reads back the trigger line values. (Source is attached).  

I am not seeing the expected behavior.  The Trigger lines do not appear to propagate to other FPGAs.  Example:

My 1085 chassis is configured as shown below.  The FPGAs reside in slots 4,5,6. The triggers only need to propagate to those slots (4 to 5,6.  5 to 4,6.  6 to 4,5).  

QUESTIONS:

1)  Do I have any NI MAX configuration issues based on what I'm attempting?

2)  Is there an explanation for why PXI Triggers are not propagating to the neighbor FPGAs?

3)  Are there any additional trigger configuration steps needed in the host app beyond setting the trigger line reservation for each FPGA?

My next steps:  

1) Question the other designers to see if anyone is using Trig 5,6,7 which should have been reserved for my explicit use.  Perhaps some VI is driving certain triggers low?  This doesn't seem likely.

2) Redesign the synchronization scheme to do master/slave sync.  Host writes trigger to FPGA 1, who uses one trigger line for FPGA 2 and FPGA 3.  This was not my original intent, because I didn't want to be locked into setting one specific FPGA as the master (the system may use 1 or more of duplicate FPGAs, and I need wanted more flexibility).

Thanks for any help folks!

-J

[VA.KI]

Hello JJMontante,

Have you see this document?

Have you try to use examples from LabVIEW?

[JJMontante · Accepted solution]

Thanks for the response.  In this case, the link you provided was not the type of synchronization required.  That is synchronizing clock edges, which is not the phenomena I was looking for (and is automatically performed on FlexRIO devices like the ones I am using).  Instead, I was looking for suggestions on why the trigger lines were not transmitting from slot to slot, for the purpose of initiating higher-level functions rather than having the digital logic work in lock-step across cards.

My colleague and I solved the problem however:

Within a single-cycle timed loop:

1. Define the logic that will control whether the trigger line is read or written. Let's assume that "True" is writing to the PXI_TRIG, and "False" is reading from it.
2. Do not make use of the "IO direction" node that would define the IO's direction by reference. Instead...
3. Create a case statement, with the selector terminal wired to the result of the "IO direction selection" logic in step 1.  
4. n the true case (write to the PXI TRIG), place an IO node, select the PXI Trig line, and set it to write mode, such that it will accept an input.  Example shown:
    
   

   Here, the input is propagated downstream to the synchronization logic, because the design needed to know that the trigger had been sent, and to wait on acknowledgement from other flexRIOs in the design.

5. In the false case, do the reverse.  Place an IO node, select the PXI Trig line, and set it to read mode, such that it will produce an ouput.
   
   
   
   
    In this case, the node is not generating the trigger, but rather waiting on the arrival of the trigger, so the input terminal is unwired.  The downstream sync logic only uses the trigger read value.
6. If the output is unused because the PXI line is being written, make sure your case statement sends down a 'neutral' result downstream, or disables logic that would be put into an undesired state when the PXI trigger IO node is not configured as a 'read'.

This use of case statements forces mutual exclusion of read/write for the tri-state logic on a bidirectional buffer (the PXI-TRIG lines), and solved my problem.

-J