LabVIEW FPGA Idea Exchange

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 working with alot of fixed point math (think FPGA development), unless you are content to simply let LabVIEW decide what precision you want in your fixed point data types, it is extremely cumbersome to (right click->properties->Output Configuraton->Uncheck Adapt to source......, close window, move to next function and repeat and repeat and repeat. This is especially true if you end up needing to highly optimize your code.

 

It would be nice to have something like a floating window that could be opened that would display the output configuration data for the selected function or control and allow editing without the need for multiple mouse clicks. The window would automatically update with the configuration of whatever function or control was currently selected.

 

Hello,

 

I have a LabView project which includes a Windows part and a FPGA part.

 

To simulate my windows part i use Conditional Disable Symbols in order to bypass the FPGA calls. ( Ex: DEBUG = TRUE/FALSE)

 

These project Conditional Disable Symbols are not used im my FPGA Vi's. 

 

BUT, when i change the Conditional Disable Symbols values ... i have to rebuild my FPGA code !  This is not good !

 

The "Bitfile validity" check should be a little more intelligent.

The "bitfile update detection" should only take in account the Conditional Disable Symbols it uses.

 

Thank for reading.

 

Manu.

Hi,

Simple one that I have heard a number of people request.  Why is there no auto-increment on the versions of an FPGA build specification versus any other versioned build specification in LabVIEW?  This should be a simple addition to bring the FPGA module inline with other LabVIEW modules.

 

Cheers,

Mac

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.

 

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. 

In addition to the gates and math functions that are available on the FPGA palette, some

basic functions should also be availble:

 

up/down counter

flip flops

mux/demux

 

Thanks,

-Chuck Reed

 

Hello,

 

For the moment, there is only one clock assigned with the FPGA main VI. "The top level clock"

This clock is used by the code created on the main block diagram. (Outside SCTL)

 

Today, if you need an other clock ... you have to use SCTL's ... but using SCTL generates many problems, because not all instructions are allowed in SCTL's ! 

 

I think that XILINX can handle a kind of partition ! 

 

My need would be, for example, to have one partition running at 40MHz ... and an other at 80MHz ... without having necessary to use SCTL's.

 

This is only an idea ... i think that behind my idea something heavy must be done !

 

The Top would be, to be able to share data between the different partitions (using FIFO for example) ... but i think this is one more difficulty !

 

The partition mechanism could be created in Labview FPGA as follow  ...

 

 

• With multiple top VI's : On per partition
• Or, with a special structure in the main vi block diagram : Partition structure, with a clock as input : Like a mega SCTL, without SCTL limitations.
• Or, by adding a clock input to the while loops
• ...

 

 

Thanks for reading.

 

 

 

 

I know its not necessarily a LVFPGA issue, but its us LVFPGA users that use fixed point numbers most often.  Why don't fixed point numbers always show coercion dots.  If every unnecessary numerical digit wastes chip resources, then isn't it more important that we know about these coercions so that we can avoid them?

 

The Control / Indicator pull down menu gets unwieldy with a lot of Controls on the FPGA Front Panel. 

 

I would like to be able to sort the names alphabetically so they are easier to pick in the pull down list.

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/highl...

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

If I kick off a compile behind my VPN I can't re-connect to the compile when I get back to the office (different IPs?).   I know this isn't a typical use case, but when compiles times or queues are long I kind of have to work around the compiler's schedule (and occasionally work from home). 

With LVFPGA I work almost exclusively with fixed point numbers, and having to convert my numbers to 8 bits or 16 bits just to use the scale by power of 2 function isn't convienient.

 

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.

We can programmatically mass compile VI's and build executables but there is no easy method to compiling FPGA code.  We have a large application that consists of C++ and LabVIEW code.  We have automated our build process but we still have to compile the FPGA code using a procedure.  It would be nice to write a script or a VI that would compile all of our FGPA code.

Hi,

 

I realise that parallel for loops don't work on FPGA because they are designed to create multiple threads which FPGAs don't have.

 

However lets take the scenario that I have 8 channels of data to process (scale, filter etc.) but do not have time to do this sequentially due to high loop rates.  Could parallel for loops be a way of doing loop unfolding on FPGA rather than forcing me to have 8 parallel paths of identical code?

Cheers,

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.

Hello,

 

I would like strongly suggest to support a driver for Spartan-3E-1600Kgate Development Board.

 

Thanks