LabVIEW FPGA Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Improper use of Global Variables in a SCTL causes compiling error 61056.

 

Currently, this error does not alert the user until a considerable amount of time has been used during compiling.

Please include a check in LabVIEW for inproper use and alert user before compiling. 

 

*Created for service request per customer recommendation.

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.

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)

mars_pm3_350.jpg       mars_pm3_350.jpg

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:

 

loop counter fpga.png

 

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.

 

failed timing.png

 

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.

 

counts waited.png

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.

Currently the SMB Trigger is connected to the Real-Time controller to act as a DIO or drift correction for the RT clock. Some applications require sub-millisecond accuracy with the trigger which is not possible with the current configuration of the SMB trigger. This idea is to connect the SMB Trigger to the FPGA as a DIO line to achieve better accuracy.

-Ryan

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.

 

FIFO Editor.png

In a FPGA code, when you click in a function (Math, Array or Comparison) to create the first constant, control or indicator, like in an Add function, it's created as a Double (DBL) type, which is not suitable for this target. In this case, it will be better if the data are created as a Fixed Point (FXP). In other cases, like in Array functions, an Integer (I32) may be a better option. One thing is for sure: Should not be a Double!

Typical Xilinx IP core icon like FFT and DDS looks like this - in expanded mode:

Typical Xilinx IP icons in expanded view

The connector labels are very hard to read. I guess everybody agrees on that this could be improved. And it is not that there is a "standard" narrow width to obey, for instance FIFO is wider than the Xilinx IP icons.

Thanks for considering this.

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:

 

normal property node.png

 

 

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

 

fpganode.png

 

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.

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:

Auto-Indexing LV FPGA

 

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.

 

2.PNG

 

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.

Auto-Index Pop 

 

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.

4.PNG

 

 

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

Old Title: FPGA Case Structure Needs To Display Enum Values

 

In LabVIEW the case structure can show enum values, while the FPGA case only shows the numeric value. Would like to see the below example capable in FPGA.

Untitled.png

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.

For some application, I find myself configuring memory blocks for the storage of custom controls which I am maintaining with a type def.  Type definitions normally have the advantage that changing them will update them everywhere they are used.

 

Unfortunately, when I change a type def control for which a memory block has been configured, the memory block does not update this, and my code breaks.  It appears that the memory block disconnects the control from its type def when configured.  It would be nice if the memory block was reconfigured - as this is what I would expect to happen with a type def control.

Working on the FPGA, I use fixed-point precision numbers quite often.  I have grown tired of selecting the FXP representation from the right-click contextual menu (block diagram or front panel), only to then right click again to navigate to the "size" tab to select the configuration.

 

The default configuration is very rarely what I need it to be -- there should be a faster way to change this.

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:

 

AutoIndexed For Loop

 

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

 

SCTL

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):

 

SCTFL

 

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).

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:

 

AutoIndexed For Loop

 

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

 

SCTL

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):

 

SCTFL

 

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).