LabVIEW FPGA Idea Exchange

With availability of fast FlexRIO cards (such as NI 5761) and FPGA framegrabbers (NI 1483, PXIe-1435, NI PCIe-1433 ) data rates of 1GB/s are becoming commonplace.  However, the FPGA Module is limited to communication only with 32-bit LabVIEW. Since, typically you want to store more than 2 seconds of data in RAM,you would like to use 64-bit LabVIEW as your host application.  Unfortunately, this isn't possible yet.

 

While, I can imagine that a full blown 64-bit FPGA Module add on would be pretty difficult to build (and especially test), I believe there is a solid middle ground at this point.  I can imagine, coding and compiling the FPGA in the normal 32-bit LabVIEW environment, and then just using a 64-bit host application to Read/Write front panel controls and to read/write the DMA buffers from the FPGA.  I don't know the details, but this communication protocols could be very low hanging fruit if it's just a simple matter of recompiling a few key pieces for 64-bit operation.

 

Since the data rates passing to and from FPGAs will continue to climb, as well as the prevalence of 64-bit OS, a 64-bit version of FPGA Module is needed in the new feature pipeline.  This should also be kept in mind as other new FPGA Module features and tools are created, as planning for 64-bit compatability now will make the eventual transition to 64-bit much, much easier down the road.

When considering options, it's important to see the development and deployment price. Please put the sbRIO prices on the NI website so we can consider it.

The Tick Count function in LabVIEW FPGA can represent time periods with tick count accuracy of up to 2^32 clock cycles, that is (using the standard 40 MHz FPGA clock) about 107 seconds.

Sometimes I need to handle longer time spans, and I use this example.

 

I suggest to implement a built-in 64-bit tick counter.

 

 

 

I have several FPGA projects that require significant compile time (up to 1.5 hours), and for that I am thankful to have my compile server running on a separate computer.

 

The issue comes with the seven Pre-Compile steps that occurs before LabVIEW sends to the code to the compiler. On one particular project this action alone can take up to 35 minutes during which time I can do nothing on that machine.

 

I would like to see much of this precompile time moved from the development environment to the compile server. There already exists a mechanism for updating the user with the compile status so those precompile errors could be annunciated in a similar fashion.

 

Get the development system back online as quickly as possible.

The latest Virtex-7 FPGAs have something like 20 times the computing power of the biggest FPGA supported by LabVIEW FPGA; it would be cool to be able to get those on a FlexRIO card.

 

Other companies make FPGA boards with up to 32 GB of RAM, the biggest FlexRIO has 512 MB; would be cool to have FlexRIO cards with RAM in the gigabytes.

Writeable inputs to FPGA I/O nodes can be left disconnected without any warning (or broken VI indication) from the VI in which the I/O node is used. This can cause some vigorous head-scratching if the missing connection is not immediately obvious as in the screen shot below. For obvious reasons, FPGA controls have no connector assignment or "Recommended, Required, Optional" attribute. In that case, and to avoid playing "Where's Waldo" on the block diagram, I suggest making FPGA I/O node input connections implictly "required", and if not, the VI would be broken. This would be the same behaviour as seen with cluster nodes. 

When writing LabVIEW code for an FPGA target, the most important considerations are speed and resource usage.  By using the single-cycle timed loop (SCTL), we can increase the speed of the program by allowing more than one operation to complete per clock cycle.  We also decrease resource usage by removing the flip-flops that would be required to store values between clock cycles for the operations in the SCTL.

 

However, there are limitations of the SCTL.  For some operations, it takes significantly less resources to implement something using a for loop rather than a single-cycle timed loop.  With a for loop, one can auto-index a result at the border of the for loop (if the preallocation of arrays option is selected) to obtain a fixed-size array (valid on the FPGA).  Below is the simplest possible example:

 

 

The equivalent with a single-cycle timed loop would be:

 

The replace array/subset VI consumes resources proportional to the size of the array.  Depending on the operation being performed, this can increase resource usage such that it is more practical to use a for loop (as shown above).

 

I propose the creation of a single-cycle timed for loop.  Here is a very rough mock-up (MS Paint is not the most adequate of image processing tools... you will get the idea):

 

 

This solves two problems: 1) It allows for the compiler to know how many times to loop will run at compile time.  It also simplifies the UI by letting the user know how many times the loop will run without having to think through a condition.  2) It allows for the more efficient creation of fixed-size arrays through a SCTL (rather than through a for loop).

The first thing you hear about programming FPGAs with LabVIEW is: use single-cycle loops. But if you build a state machine (while-loop + enum + case structure), in many cases you cannot make the outer while loop in a single cycle-loop, because not every state fits into a single-cycle loop. Therefore you have to place the single cycle-loop into every case, which has to run in one cycle, which takes up block diagramm space and is cumbersome. Therefore my idea to create a single-cycle case structure: it uses the same compiling mechanism of the single-cycle loop on every case, which is capable of running inside a single cycle. It would be nice, if this behaviour is configurable, meaning I can decide from case to case, if it is a single-cycle case or not. Some kind of right-click menu options like these: "make this case single-cycle", "make every possible case single-cycle", etc. Of course the mode of the case (single-cycle or not) should somehow be displayed.

 

Regards,

Marc

Problem:

Auto-Indexing of LabVIEW is extended to LabVIEW FPGA, only with one small caveat. You can easily auto-index into a loop, but not out of it. You will understand this better if you've already worked with LV FPGA.

In the FPGA paradigm, we enforce compile time resource determinism, by making sure all our arrays are of a fixed pre-determined size. In auto-indexing out of a loop, we may not know what the size of the array is, and hence it breaks the VI with the error "Arrays must be of fixed size". Try to write the following code in LV FPGA, for a better picture:

 

Solution:

The current workaround is that we have a fixed size Array which we then use in and out of the loop, replacing its

elements, as shown below.

 

 

However, an easier and much much more intuitive solution for users would be to just right click the auto-indexed tunnel and set the dimension size.

 

 

This definitely means that the number of data flowing out of the loop could be more than our fixed size. We handle that case by providing the user with the "In case of overflow" option.

 

 

This would ease our effort in coding LV FPGA as much as it would would improve intuitive coding. Vote for this idea if you think it would make your life a tad bit easier.

At present, if you are trying to simulate your FPGA's actual logic, using a custom VI like this:

Then you know that your custom VI test bench only has one case for methods (just a general method case, not a case for each method available). There are ways to get around this problem--for example, this example emulates a node and suggests using a different timeout value for wait on rising edge, wait on falling edge, etc, but one still has to write the code for the different methods.

 

My suggestion is as simple as this: make test benches easier to use by handling all of the methods and properties with a set behavior. That way, all one has to set up when creating a test bench is the input and output on each I/O read/write line. At the very least, it would be nice to have the ability to read what method is being called, so the appropriate code can be set up without complicated case structures.

My original problem was that I in the FPGA have an array of data, where I need to do some calculation, where the only appropriate way was to use a pipeline. The pipeline is a very strong tool in the FPGA, but I think the LabVIEW tools could be changed so the pipeline is easier.

 

My old implementation if the pipeline:

 

Suggested implementation of single cycle pipeline, with shift registers in the tunnels, so all the code is run on each of the 5 elements in the array.

Maybe there should be added a number of iterations (like the “for loop”), if the number of data, is not defined by the array size.

In another project I have a continuous running pipeline, I have implemented in different ways, but one simple is as shown:

 

Before

 

 

 

Here the new pipeline sequence could also be used, maybe like following:  

 

 

Here it should be stated in the loop tunnel, that the input data is read continuous.

Here I have shown in both examples, that it should be single cycle times loops, but maybe the pipeline structure should also be able to run with another timing (determined by the slowest frame).

I have seen the idea about the timed frame, it will help on the last example, but there will still be need for a pipeline structure.

Like a Formula node or a math script node why not a RT node that will support Verilog and VHDL? Yeah yeah i know the time taken to code will take a hell a lot of time compared to what can be sweetly done in lv (So dont compare) but at times verilog support will have its advantage.

Hello,

 

It should be nice to be able to get some general informations, on windows,  about a FGPA VI using its reference.

 

For example it should be interesting to get ...

 

 

• The main cycle loop frequency
• A version ID 
• The CRC of the bitfile
• ...

 

It sure would be nice to take advantage of timed loops when your FPGA is dictating the timing of your host code with IRQs. DAQ and XNET can make timing sources to drive the timed loop, why not LV FPGA?

 

I'm imagining a "Create timing source from IRQ #" VI. # input and string output along with the reference wires.

Hello,

 

In Labview 2010, the implementation of INLINE VIs has been improved. But this feature is not aivalable in Labview FPGA.

 

When you are looking for ticks/space you have to replace the VI calls by their content ... and then the FPGA VIs becames rapidly unreadable.

 

I think that inline VI could be very interresting in FPGA because ...

 

 

• Ability to create userfriendly / updatable / readable / clear FPGA diagrams 
•  Optimize the time/space needed to call a real VI

 

When writing LabVIEW code for an FPGA target, the most important considerations are speed and resource usage.  By using the single-cycle timed loop (SCTL), we can increase the speed of the program by allowing more than one operation to complete per clock cycle.  We also decrease resource usage by removing the flip-flops that would be required to store values between clock cycles for the operations in the SCTL.

 

However, there are limitations of the SCTL.  For some operations, it takes significantly less resources to implement something using a for loop rather than a single-cycle timed loop.  With a for loop, one can auto-index a result at the border of the for loop to obtain a fixed-size array (valid on the FPGA).  Below is the simplest possible example:

 

 

The equivalent with a single-cycle timed loop would be:

 

The replace array/subset VI consumes resources proportional to the size of the array.  Depending on the operation being performed, this can increase resource usage such that it is more practical to use a for loop (as shown above).

 

I propose the creation of a single-cycle timed for loop.  Here is a very rough mock-up (MS Paint is not the most adequate of image processing tools... you will get the idea):

 

 

This solves two problems: 1) It allows for the compiler to know how many times to loop will run at compile time.  It also simplifies the UI by letting the user know how many times the loop will run without having to think through a condition.  2) It allows for the more efficient creation of fixed-size arrays through a SCTL (rather than through a for loop).

Dear All, 

 

I am attempting to write some FPGA code, for a cRIO 9074, to act as a data logger for 50 sensors that I am fitting to a small lifeboat. I hope to save all the data to the 9802 SD card module. From my understanding, it should be possible to take the sensor input signals into the FPGA chip, compile them into an interleaved data group and then output them straight on to the SD card from the FPGA. This means there is no RT controller required; making the system more reliable and quicker. Is this correct? Or is my knowledge wrong?

 

I have tried to look for some example of this on the web but I am struggling to find any which do NOT use a RT control. Can anyone point me in the direction of some examples?

 

Few extra details: Sampling frequency  = aiming for 10 KHz (will be reduce if system cannot handle it), Input modules include; 9236 strain gauges, 9234 accelerometers, 9205 analogue voltage inputs, anymore questions fire away. 

 

Thanks in advance!

Pete