FPGA FIFOs (to C/C++) - single commanding and response or multiple?

[lsstpkubanek]

Dear group,

I would like to use cRIO as middleware accessing serial and other ports on external buses. How should I split the responsibility of writing to FIFOs? I thought about two possible designs:

• route messages through a central multiplexer, which decides where to put the commands and access replies (e.g. a FIFO will take command followed by data to send to the serial port, and another FIFO to get responses on the serial port)
• multiple FIFOs, two per serial ports (transmit, receive)

I do understand the difference between approaches, believe the second offers much higher parallelism (I can send commands to multiple ports). I do understand the second approach doesn't offer synchronization, which I should handle in the FPGA/control program (e.g. when I want to make sure a command is sent to all serials at the same time, I do need to create a synchronization point and make sure data from FIFOs start to be transmitted at once synchronization point is unlocked).

Are there any penalties and possible arguments I should pick the first with a central FIFO mux/demux?

Is there a limit to the number of Target<->Host FIFOs (except for obvious memory)? Are Target<->Host FIFOs more expansive?

Do I understand correctly I cannot use Target<->Host FIFOs in SCTL, so I need to copy data to internal FPGA only FIFO before using it inside STCL for writing/reading?

Thanks

Petr Kubanek

[rolfk]

There should be no problem to use exactly ONE Read or Write node to a DMA FIFO (your host->FPGA or vice versa) in a SCTL. What you can't do is having more than one such Read and/or Write to the same FIFO anywhere in your diagram if you want to put at least one of them into an SCTL.

If you try to put two or more Reads or Writes to the same FIFO into one or more SCTLs then LabVIEW will complain even if it is basically impossible that both can be executed in parallel (for instance you have a state machine in the loop where at any time only one of the states can be active but you want to read or write from two states to the same FIFO. The LabVIEW compiler can't translate your diagram with the case structure for the different states into the fabric like it looks on the diagram but has to unroll each of the cases into a parallel piece of code that executes in each loop iteration anyhow, but nodes like the FIFO Read or Write are inhibited through an implicit disable pin when they should not be executed.

[lsstpkubanek]

Thanks for the reply. That's what I know. I also know you can manage to put two writes into a single FIFO in STCL, LabView will not complain during compilation but FPGA will crash silently during execution. You just need to mask second write into non-trivial if switch.

But that wasn't the main question. The more interesting is to know if there are any limits on number of Target<->Host FIFOs and if multitude of those will make final design slower. I don't think so, but hearing the answer before measuring it myself would be great.

Thanks

Petr Kubánek

Vera C. Rubin Observatory

[rolfk]

I'm definitely not able to put two FIFO Writes to the same FIFO in the same (or different) SCTL even if they would never execute concurrently. The compilation stage before sending everything to the Xilinx toolchain already complains about this.

LabVIEW 2018 SP1 if that might matter.

[lsstpkubanek]

2018 SP1. Just put FIFO writing into subvi, and use this subvi twice from a control panel in SCTL. Call one subvi in a case (true/false, doesn't matter). LabView will happily compile that, yet sometimes FPGA will crash during execution when hitting the two writes.

[lsstpkubanek · Accepted solution]

cRIO 9039 has 16 DMA channels which can be used for FIFOs. So once you need to implement more than 16 FIFOs, you need to mux/demux. I cannot think about any other penalty and would advise to use FIFOs without mux/demux as much as possible, bearing the limit in mind.