LabVIEW FPGA Idea Exchange

Community Browser
About LabVIEW FPGA Idea Exchange

Have a LabVIEW FPGA Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW FPGA Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW FPGA Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW FPGA!
Top Kudoed Authors
User Kudos Count
1
1
1
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
0 Kudos

The error cluster has a string to identify where the error occurred, "source". In a FPGA code the string is only accepted (no broken run arrow) inside an error cluster. I guess this is implemented in this way to maintain code compatibility when you move code to another kind of target. The problem is that doesn't matter what you write in these strings when you are in a FPGA environment, it's ignored.

Some people use the same error code to show a kind of error changing only the source to identify where. I got a software, written by somebody else, that used error code 5000 in all user defined errors, changing only the "source" string. That give me no clue where the error was happening.

Since in a FPGA target only the "code" is useful i a error cluster, I propose two solutions:

1) A warning when a string in a error cluster is not empty (compilation time);

2) The FPGA compiler converts the ASCII chars in "source" string of the error cluster in a fixed size array of bytes [U8]. This array will be converted into a string in a target that can handle it. This is very common when you read a error cluster indicator in a FPGA VI from a RT VI. This solution will have a little overhead but it maintains 100% compatibility.

I like the second solution a bit more. A limited number of characters should be allowed order to save memory. One solution to that is to have a configurable option to determine how many chars is the maximum allowed.

I love using enums because they can often make discrete options much clearer. Example:

enum clarity.PNG

But, at least as of 2017, the below code is going to use fewer resources and propagate faster because LabVIEW is going to use an 8 bit register above instead of the two bits below. 

 

My solution is to allow smaller integer representations of enums (I'd use a U2 in the above case).

 

Ideally the user wouldn't even have to specify the integer size, it could just calculate the minimum at edit time and show the user what it is.

0 Kudos

VBAT input voltage in VBAT Requirements of sbRIO-9651(SOM) should support less Voltage.

 

SPECIFICATIONS NI sbRIO-9651

http://www.ni.com/pdf/manuals/376962b.pdf

 

VBAT is for keeping the time on RTC.

Minimum of VBAT input voltage in specification is 2.875V.

In general, the button cell is used to keep time like a Mother board of PC.

For example, CR type Lithium button cell has Nomal voltage 3V and End-point voltage 2.0V.

In this case,  if we follow the specification, we can not use this CR type lithium button cell . Many users would like to use this CR type button cell for RTC. So, if we can chang the specification of Minimum VBAT voltage from 2.875V to less 2.0V, it is easy to use in many cases.

 

of

0 Kudos

Currently, in LabVIEW you can right click a VI's icon at the top right of the front panel to find all instances including where the VI is referenced in a static reference node. Also, when you use have a "Open FPGA VI Reference" in "build specification" or "VI" mode, you can double click the node to open the referenced block diagram. Once the FPGA front panel is open, there's no easy way to get back up to the caller. It would be cool if we could extend the right-click-find-all functionality so that when you right clicked a top level FPGA VI, it would search where that VI was referenced in any "Open FPGA VI Reference" nodes. Currently, when you right click and search, it just says no instances found.

0 Kudos

When debugging FPGA code, I still like creating debug code right there in the FPGA code with FP debug indicators.  After some simulation I can then compile (the exact same code) and test with hardware.

 

The IDE, however, makes my life really hard.  In the background, each VI has a default build spec or bitfile associated with it.  When a tiny tiny change occurs in the source code (some of which seem overly sensitive BTW) the interactive mode will not start.

 

It would be nice if we had the option, assuming that the FP controls are identical, that we can start an interactive mode where the existing bitfile is used with the same FP of the VI source.  A visual indicator that the bitfile MAY NOT be identical with the code would by a good idea.  Sometimes changes are trivial, sometimes when fixing a bug, we might want to double-check old behaviour for a moment before starting a compile process.  The ability to maintain the option to execute the last compiled code seems like it would be a nice addition.

 

And yes, we could make a RT app which interacts with the FP elements but since debugging code changes often (including FP elements), this is a problematic maintenance issue.

0 Kudos

I know this is not easily possible, but if there is a way to emulate FPGA compilation and quickly show the maximum achievable frequency(even approx will do) during development, would be one hell of a feature

Why the "Stacked Sequence Structure" is still present in the FPGA palette? It has been removed from other targets palettes. I think it's better not be in the FPGA palette also.

0 Kudos

I find that I'm using large bit FXD to handle the dynamic range, but I only have 8 or 16 bit significant bits.  I have an I2S input of 24bit numbers that I store in memory as U16 with the following incoding Number = A*2^(B), where A is a FXD(+/-11,9) and B is a FXD(+/-5,5).  A and B are bit spliced array that form the U16.  This allows me a 33% memory reduction covering a greater dynamic range by trading off resolution.  Here the I2S input allows the counting of leading zeros or ones to create the number B and conversion back to 24bits is easy.  Three items would make this a great help: 1. a typedef, 2. a quick forward convertor from standard form to FP FXD, and 3. gain inputs on math elements such as FFT if they canhandle FP values.

FPGA registers would be more user friendly, if they could be quick dropped and also searchable (find caller as has been suggested before). This would be also great for handshakes.

0 Kudos

Labview FPGA development environment supports single precision datatype and nowadays with bigger FPGAs they are lot easier to fit in. I started using CLIP/IP integration node with Labview FPGA environment only to find out the single precision is not supported via this. It would helpful if this is supported in future Labview versions.

If I am choosing to offload multiple FPGA compilations to either a local or cloud compile farm, can we not at least do the itnermediate file generation in parallel?  Our current design takes approximately 10-15 minutes to generate intermediate files.  For 5 Cloud compiles, this blocks my IDE for around an hour.

 

Since the file creation processes are independent of each other, why can't we do them in parallel?

In this thread, I learned that you can't change the sbRIO analog IO to Raw. I would like that functionality to help reduce FPGA resource usage.

raw sbrio2.png

When instantiating case structures, the bit width of the selector has an influence on the efficiency of the code being produced.  Of course various compiler optimisations will (may?) do a lot of this lifting for us if we actually wire in an FXP (which LabVIEW again tries to coerce to I32, but that's another battle) but I'd like to have the ability to create, use and convert to and from enums with variable bit-widths.  Of course the only parameter of importance for this is the width of the FXP, the integer bits become essentially irrelevant.

 

I currently have to do a lot of U8 Enum FXP conversions in order to be able to force my case structures to adapt to a given width when supplying an enum to control some code.  Readability would benefit greatly if the enum itself could "simply" be an FXT to begin with.

I don't like static resource definitions FIFOs, Block RAMs or DMAs in my projects.  I prefer to have the code declare such entities as they are required because this makes scalability much easier to achieve.

For FIFOs, BlockRAM and so this is no problem, but there are two things we currently cannot instantiate in code:

DMA Channels

Derived clocks

 

To deal with the seond option: Why is it currently not possible to create a derived clock in code.  The ability to automatically have one piece of code accept a single clock reference and let one loop run at a multiple of the speed is something I've wanted to be able to do in the past but it is currently impossible in LabVIEW.

 

Please let us configure / define derived clocks in LV code.

I don't like static resource definitions FIFOs, Block RAMs or DMAs in my projects.  I prefer to have the code declare such entities as they are required because this makes scalability much easier to achieve.

For FIFOs, BlockRAM and so this is no problem, but there are two things we currently cannot instantiate in code:

DMA Channels

Derived clocks

 

To deal with the first, why can't we define a DMA channel in the code?  When parsing the code before compiling, the presence of a DMA channel can be autodetected and added to the interface for the Bitfile. 

 

To try to decouple my code from static DMAs, I actually have started defining my core FPGA VIs as accepting FIFOs with Write functions (For DMAs to host) or Read functions (for writing to FPGA) required.  I can then, without having to change my project, wrap this FPGA VI in another VI which can then input wither a DMA channel (which unfortunately must be defined in the project) or a standard FIFO which cen then be used for debugging.

 

Please allow for the instantiation of DMA channels in code.

Currently, when you put a fixed point number into a case structure, it uses the next largest integer and you get a red cooercion dot:

Allow fxd point integers in case structures.PNG

 This is unfortunate because, you have to have a default case. It would be nice if the case structures could take the fixed point type since there's isn't any of the ambiguity that exits with floating point. Using a smaller number for the selector might also provide an optimization.

 

 

In correlation with another general idea I have posted, I have come to the conclusion that it would be nice to run an analysis of the Xilinx log in order to give feedback over which code has been constant folded by the Xilinx compiler.

 

Other aspects such as specific resource utilisation would be really cool also (SRL32 vs Regsiters for Feedback nodes).  This would obviously be a post-bitfile operation but could at least give some direct feedback as to what the Xilinx compiler has modified in the code (Dead code elimination, constant folding etc.).

NI has released an exciting new product with the High-Speed Serial board which is essentially a Kintex 7 with GTX transeivers exposed.

 

http://sine.ni.com/nips/cds/view/p/lang/en/nid/212693

http://sine.ni.com/nips/cds/view/p/lang/en/nid/212695

 

Some applications we are working on would benefit greatly from having some way to expose the GTP / GTX / GTH transceivers ont he various NI FPGA boards to enable high speed serial transmissions on a wider product palette.  Even the Virtex 5 supprts up to 16 GTP transceivers.  Having even 8 of these available for Aurora communication would be a complete game changer as we could move over to optical links between individual devices.

 

In order to be able to make proper use of this, NI needs to offer GTX / GTH / GTP options for many of their boards.  Imagine the power which could be unlocked by itnerfacing 8x Zynq 7010 boards with a single Kintex 7, each Zynq performing some aspect of pre-processing (Analog control, switching, some aspects of control) before sending results back to the Kintex 7..... For those of us working in Scientific areas, the prospects of a system like this is truly mouth-watering.

I hope the FPGA Register Function Could Add "Find Caller"....

 

1.png

 

2.png

0 Kudos

Currently, you can't put analog IO nodes in SCTLs because it takes more than one cycle to write them. Can we have a handshake interface to them? Here's an example of what an anlog output could look like:

 

AO SCTL2.PNG