NI FlexRIO Development Tools Discussion

[dklipec]

Do you require pretrigger samples?  If not, then you would be best suited by just using a counter instead of the record state machine.

If you do require pretrigger samples (most applications in practice do), what latency to rearming the trigger can you tolerate?  If your trigger period is relatively large compared to your record period, then you can use the "Simple" acquisition engine.  Simply change it to use the U64 data type and use the Join Number LabVIEW node to build up a 64-bit integer from your 4 16-bit integers (and adjust the host side code accordingly).  You can find this example in LabVIEW\examples\FlexRIO\FlexRIO Building Blocks\573X\Simple.  There are three example FPGAs in this one project. 

I would recommend starting with the Multiple Records personality.  In this case, you can modify the multi record version of the example to use the "single record" state machine VI (LabVIEW\instr.lib\FlexRIO\Libraries\Acquisition Engine\FPGA\Implementation\acqEngineRecordStateMachine.vi).  This removes the record count input and makes the acquisition always reinitiate on a start trigger, with no maximum count.

You may wish to increase the size of the "To Host FIFO" DMA FIFO to insure that you have sufficient buffering to never back up.  PCIe traffic can be bursty at times.  However, if that happens, the VI will simply throttle the acquisition to prevent it from triggering.  No acquired data will be lost.

acq.Initiate is level sensitive.  It will abort if it goes false during an acquisition.

If you require a very large number of pretrigger samples, you may need to fall back on a DRAM acquisition engine (like the Instrument Driver personalities).  This can be made to work, but it will be harder to make it support continuous acquisition.

[loera]

Greetings,

I have the following system:

1 - NI PXIe1082 chassis

1 - NI PXIe 8133 Controller (RTOS)

2 - NI PXIe 7965R FPGAs

2 - NI PXIe 5781 Digitizers

2 - Ettus XCVR2450 RF Transceivers

Running LV 2011

We are working on a communications system.

One thing that we have been having difficulty with is the handshaking between different processing sections in the code.

We came across the "4-wire protocol" and have been trying to implement it.

When we loaded the FlexRio Dev Lib we saw that it actually has some VIs to help us implement this protocol.

However, the blocks do not have any documentation with them.

Q1. Is there documentation for them? Will there be soon?

We are running in SCTLs ranging from 50 - 150MHz.

Q2. Are the "4-wire" blocks in this library meant to run a certain speed?

Also missing from the library is a bit unpacker.

For efficiency it is desirable to have a block that will unpack a U64 or a U128.

the "4-wire" protocol is definitely needed here.

I am attaching our FPGA block that does this (U64 --> bit-unpack)

We have not tested this block extensively but would like to present it to the community for improvement.

This is definitely a Library that is useful and needs to continue to expand.

Thanks,

-loera

[dklipec]

So, the 4-wire blocks that are in the FlexRIO Instrument Development Library are there as a way of allowing a user to create a 4-wire interface without having to think about the 4-wire semantics, with an implementation bias toward high throughput (the 4-wire block looks almost exactly like a shift register from a timing perspective).  The truth is that there are a number of ways to implement handshaking that will make trade-offs betweeen efficiency and abstraction, but that discussion is a little too involved for a forum post.

Relevant to your VI, you could use the 4-wire block to success because you have a 64-bit input.  You would simply connect your logic to the 4-wire block, but send it the Ready For Output when you consume the last bit of data on a Ready for Output.

The 4-wire block has been successfully used in large designs with 250 MHz clocks, so I would expect it to run with no problems in your situation.  However, since you have an internal need for multiple states (1 valid input = 64 valid outputs), it isn't ideally suited (it would work, but it would not be significantly simpler than what you already have).

A couple of other notes, if you use the rotate right primitive (and feed it back instead), that will have much better timing performance because there will be less mux behavior.

I've attached a VI Snippet with some comments and suggestions.

[loera]

dklipec,

I appreciate your feedback. I have implemented some of your changes.

In the diagram that you sent, the 3 input OR gate connected to the CASE structure will still execute the TRUE case even though "ready for output" is low.

This of course is not desirable because it will send the next BIT from the U64 but the next block downstream from the unloader is not ready to recieve.

It is true that it will not send a "T" output_valid signal, but it will have lost a bit.

I think my current code fixes this problem, however, I am now dropping every third U64 word. It is very strange.

I will attach code soon, I hope.... The attached picture is the beginning of our transmitter FPGA code.

At the top left you will see a right bit shifter. That is our current "hack" to get this code working.

Without that hack I will drop every 3rd U64 word. It is very strange.

I hope to be able to find the bug and post the working code. Feel free to examine.

Thanks again,

-loera

[AmitShachaf]

Hi Ryan,

I am working with OEM board. It is the PCIe-1473R. Could I use some of the functionality in this tools for this card?

It is not FlexRIO.

Thanks - Amit,

[dklipec]

There are certainly a lot of tools in the library that can work on a non-FlexRIO target (anything at all supported by LabVIEW FPGA).  Many of the tools are single-cycle timed loop centric, but most will work just fine in standard while loops too.

A lot of the acquisition/generation engine example code is application targeted toward digitizers and waveform generators.  This may not apply particularly well with your application on a frame grabber.  But the other components (particularly in the Helper VIs section) will probably apply.

[o.fujioka]

Hello,

This is Osamu at NI Japan SE

I just want to say thank you so much for your wonderful FIDL and enjoying coding with FIDL a lot! 😄

I have recently implemented several different FlexRIO apllications, using 5734 / 5761 / 5772.

Just a little showing off of my FPGA VIs with FIDL for other FIDL users...

[1. Inner Vector Calcurations on 5734 multi record + 7962R (took 4 days)]

[2. Integral Value Calcurations on 5772 multi record + 7962R (took three days)]

For 5734 and 5772, onboard processing was required and the data throughput was down scaled to less than 100MB/sec.

Also, not so many pre-trigger samples was required (less than 10usec for requested number of samples for pre-trigger)

Therefore, I have only used the VIs on FIDL >> Acquisition Engine, and not used any DRAM or DRAM related APIs in FIDL.

In my sense, the combinatorial usage of following tools is tremendously powerful.

1. LabVIEW FPGA Simulation

2. IO simulation with Custom VI

3. FIDL

To acheive better stress-free environment, high power CPU is recommended because the simulation with FIDL is very heavy.

Again, thanks for your wonderful masterpiece, FIDL.

Best regards,

Osamu

[Pie566942.0]

Hello Osamu,

It would be beneficial to hear any experience and guidance on FPGA simulation.  In particular, the use of 3rd-party tools, timing analysis, especially with external interfaces like IO and DRAM.

Regards,

Steve K

[o.fujioka]

Hi Steve,

Thanks for your comment.

I am ashamed of myself that never challenged any simulation on Timing or DRAM. 

I only did simulation on IO and codes on LabVIEW FPGA.

I would definitely like to hear somebody's experience of Model-Sim timing simulation and any other timing and DRAM simulations.

Thank you.

Osamu

[James_McN]

Hi,

Thanks for the library. It definately helps and I actually think it would be great to see some of the utilities in core FPGA. e.g. Counters/Rising Edge/Latches as I find myself using this library on many projects where these are required.

If possible though it would be good if this can be distributed as a VI package, it would make it easier to install to multiple versions although I realise there may be implications for palettes etc. never tried VIPM with FPGA only IP.