LabVIEW FPGA Idea Exchange

Top Authors

User

Kudos

Post an idea

FPGA Graph handling

I've developed a small test utility for testing FPGA code on my windows machine before proper FPGA testing and have noticed something I think could be improved.

If I have a graph or any other indicator with DBL default data type within a conditional disable, the compiler still throws an error regarding an unknown state (DBL). Although the terminal is in the diagram disable, the object seems to remain on the FP (but also in the code being sent to the FPGA compiler).

Can we actually remove the graph (or other culprit control) in the background before starting the actual compile so that I don't need to drop and re-connect every time I want to switch execution systems?

Shane.

Powering NI sbRIO device

View All (1)

memory map

When using external ram on the FlexRIO products it would be nice to have a memory map tool built into LabVIEW FPGA.

Many traditional FPGA release processes for companies require a memory map. Currently LabVIEW only allows the user to create memory partitions, but the user has no control on where the partitions are laid out in memory.

This can cause problems during the release process because the simulation is not repeatable because the memory element being accessed may be in a different location.

This feature will not impact the functionality of LabVIEW, but will make it easier to use LabVIEW FPGA in companies where Verilog, and VHDL languages were the only options for FPGA's and the release process is hard to change.

Show the price of sbRIO on the NI website

View All (1)

A smaller (and cheaper) sbRIO based on the Xilinx Zynq chip. Target size is SO-DIMM form factor (68 x 30 mm (half the area of a credit card), 200 pins). Such a board would be OEM friendly and can be plugged into a product (rather than the current sbRIO offerings that requires the product to be developed around the sbRIO rather than the sbRIO fitting into your product). Also, a Base Board that is (only) used during development. Below is what the proposed sbRIO and Base Board would roughly look like (courtesy of Enclustra FPGA Solutions)

View All (1)

The loop timer express VI is very useful to time a loop to an exact rate, however... if you want to be sure the loop is meeting the rate requested... you also have to put in tic count VIs like this:

Since the loop timer express VI already is calculating how long it needs to wait in order to achieve the desired loop time, I would prefer it if at least output a bool that indicated it failed to achieve the timing required.

It would be best if it output the actual tics it waited in like I16 form so it could go negative (indicating the # of tics it failed to achieve timing by.

View All (1)

VHDL Labview & FPGA

DC to DC converter basics using Labview for VHDL to FPGA Control

I am fairly a novice, that is why simplifications required, before I begin thanks for them who will response in advance

I am designing a DC to DC (Intermediate Bus Converter, a step down BUCK converter, of 24 v input and output 9 v and 5 amp current), By using FPGA controller, having limited knowledge, I need to program this using VHDL, for which I take LabVIEW, but as I am new so do not have any idea as what are the steps that I need to take for implementation, what function that FPGA does in this so that it can generate 24 v and what other mechanisms that have to control inside or outside FPGA that it can give the desired output voltage, if you have any idea about this then I would be glad to receive the steps that are necessary to complete this

Presently, the Xilinx Compile Tools do not appear in the MAX technical report or NI License Manager. As a result, to determine the version, users must go to Add/Remove Programs in the control panel to determine which versions they have installed. It would be great for troubleshooting if the Xilinx Version could be implemented into the MAX technical report.

In addition, the Compile Worker states that the version of Xilinx used is 12.4, regardless of whether you are using 12.4 or 12.4 SP1. It would be useful for the compile worker to note which version it is using. Specifically, often the compilation chooses the compile tools based on what it was compiled with previously. When upgrading to 12.4 SP1, the user may think the compiler automatically uses the new compile tools and has no visual cue to verify the compile tools version used.

When LabVIEW 2009 and prior, after the compilation of FPGA VI, the bitfile was automatically downloaded to EtherCAT. However, from 2010, that process became manual; after the compilation, you need to go under the Build Specification, right click on the bitfile created, and select Download. Regular cRIO does it automatically, and I don't see the point of manually downloading it.

Does anyone know the point of doing this? And if it was not intended, I like auto download a lot better. But at the same time, 2009 and prior, the bitfiles were not shown under the build specification, which bothers me also. So the conclusion is that, I think it will be better to show the bitfile under the Build Speficcation AND download it automatically to EtherCAT.

Connect SMB Trigger to FPGA

FPGA FIFO and Memory Editor

I have been working with FPGA for quite a while, and realized that manually opening and editing DMA, Target Scoped, P2P, VI scoped Memories, and project scoped memories can be very tedious and time consuming. Wouldn't it be great if there was a way to edit FPGA FIFOs and Memories from a single place. This notion gave birth to the FPGA FIFO Editor and FPGA Memory Editor. These editors would give the ability to see, create, remove, and edit FIFOs or Memories for that specific project (list both project and VI scoped items). Furthermore, their could be some additional logic built into the Editor that would alert the user when they have tried to configure something incorrectly (for instance an R Series target only has 3 DMA FIFOs, alert the user when they have configured more than that).

Listed below is a mock-up of the FPGA FIFO Editor.

View All (1)

Default data type Fixed Point (FXP)

View All (7)

On PC and RT targets, when you right click on a specific property in a property node, you can directly open the help for that property:

However, on an FPGA target, you can't open the Help for a specific property or method by right clicking:

What happens if you click on 'Help'? It takes you to a page that explains the purpose of a property node. Rarely if ever is that what I actually want. Instead, I want to know about 'Linearization Coefficient 1.' My only option is to open up the Help and search for that specific property, which may or may not be easy to find.

My suggestion is to add a direct link to the help for every FPGA property and method in the right click menu.

Enable Auto Indexing for LabVIEW FPGA

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.

I posted this suggestion in the forums, but it is something I would like to see improved and included in the FPGA library. The idea is to multiplex multiple inputs/outputs to a single high-throughput math function. If someone has to do a lot of fixed point math on the FPGA, the resources are used up quickly. The multiply block is primarily what I would like to see this implemented for, but I think it would be useful with all of the high-throughput math functions.

In one project I quickly ran out of DSP48E's on my FPGA, and since I had many fixed-point multiplies with the same data type configuration, I created a state machine to step through the inputs, allowing me to replace 4 high-throughput multiplies with one multiply block for multiple operations. Sequential operations are possible by feeding the output of one operation into the input of another (I didn't implement that in the forum post below, but it can be done). I think Labview could improve pipelining of the multiplexed function, ease of setting the number of inputs/outputs and data-type, hand-shaking logic for operation in SCTL, etc. LabVIEW could also show separate schematic figures for each of the multiplexed functions (example: a PCB layout software such as Eagle shows separate blocks on the schematic for each opamp on a chip containing multiple opamps).

http://forums.ni.com/t5/LabVIEW/Multiplexed-multiply-to-conserve-resources-on-FPGA/m-p/1668138/highlight/true#M595294

View All (1)

Support Type Cast from Integer to Enum

FPGA module for 64-bit LabVIEW

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.

View All (8)

LabVIEW FPGA Idea Exchange

FPGA Graph handling

Powering NI sbRIO device

Como configuro FPGA en el Compact- Rió?

memory map

Check for Invalid Use of Global Variables in LabVIEW and Alert User Before Compiling

Show the price of sbRIO on the NI website

Smaller (and cheaper) sbRIO based on Xilinx Zynq

New output from loop timer express VI that indicates lateness

VHDL Labview & FPGA

Make It Easier to Determine Current Xilinx Compile Tools Version, and Distinguish Between Xilinx 12.4 and Xilinx 12.4 SP1

Procedure of Downloading Bitfile to EtherCAT

Connect SMB Trigger to FPGA

FPGA FIFO and Memory Editor

Default data type Fixed Point (FXP)

Size Xilinx IP icon to fit its terminal labels

Have a Direct Link to the Help File for FPGA Property and Invoke Nodes

Enable Auto Indexing for LabVIEW FPGA

Multiplexed inputs/outsputs to High-Throughput math functions to conserve resources on FPGA

Support Type Cast from Integer to Enum

FPGA module for 64-bit LabVIEW