LabVIEW FPGA Idea Exchange

I'd like to have a dedicated FPGA Compile Server, based on a realy slim OS, e.g. damn small linux oder even PharLab? The OS does not realy matter, as far as it is multi-core capable and it should use as little system resources as possible, to get as much ressources as possible for the compilation process.

 

Purpose: get max. compilation speed

 

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.

When setting up memory in LV FPGA these seems to be one important setting missing....description.

 

Good programming practice defines that we should have descriptions in our code, similar to the VI description of a global variable. This would also help out immensely when using bit packed memory blocks to define status bytes and such as the description of the individual bit meanings could be added to the description and not having to be dropped as block diagram comments everywhere one of the nodes is used.

It would be nice to be able to use logic operators with fixed point numbers.

 

 

 

  Recompiling an FPGA VI can be time consuming when debugging a large program.  The emulator mode is not useful when the process includes debugging real I/O connections (vs. emulator simulated).  I would propose a useful "fix" to the emulator I/O problem.  Could the emulation mode have the ability to use all the I/O's as "pass through" connections from the FPGA to the host in order to actually use the I/O's.  This would involve a very simple FPGA VI that connects all the I/O's to appropriate indicators or controls.  If this pre-compiled VI is downloaded and running on the FPGA during emulation mode, then you could actually debug real I/O connections without compiling your entire VI.

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

 

When you configure Memory in LV FPGA, there is no way to find specific references to particular memory blocks using the search function. The search will show "ALL" memory access nodes, not just the ones you are looking for. Additionally a text serach will not catch the text from the X Nodes. This can be particularly tedious if you have many nodes in your hierarchy and are looking to only see references to a particular memory block.

 

I would like to see the search improved to allow filtering of the memory nodes the same way that we can search for global variables (find definition and find references)

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,

 

i would suggest some Improvements to the Timing Violations Window.

 

• Highlight the Whole Path with all Element and Wires in the Blockdiagramm when i click on Path in the Timing Violations Window.

 

• Highlight the Element on the Blockdiagramm which i clicked in the Timing Violations Window.

  

 

 

• Give the Problem Window of the Timing Violations Window the ability to adjust its size i often have to scroll. (Can be seen in the Timing Violation Window above)

 

With kind regards

westgate

When working with LabVIEW FPGA if so much as the value of a block diagram constant is changed, the entire application must be recompiled.

 

It seems that there could be a smarter method to deal with recompiling that might allow selected portions of the block diagram to be recompiled without the need to recompile the entire app.

Some of the tradeoffs might be lower FPGA utilization efficency and timing constraints, but allowing minor changes to the FPGA code without the overhead of a complete recompile would certainly make debugging applications much faster.

 

I am not necessarily proposing an implementation just posting an idea that seems like it would add value to the LV-FPGA development experience.

 

The actual "Wait on ... I/O method" has an input named Timeout ... With no unit !

 

 

So i went on the NI forum and i found this article ... http://digital.ni.com/public.nsf/allkb/0D8325309894115286256F3B00341159

 

It would be nice to add the unit in the name of the input parameter like Timeout(ticks)

 

Better idea ... it would be nice to be abble to configure the timout unit like timing objects like this ...

 

 

 

FPGA bitfiles should not have any dependency on the project name or target name.  What if you change the name of your project?  What if you change the name of the target?  These dependencies should only correspond to the VI and its location in the project tree and FPGA target. FPGA bitfiles should be in the same directory as the vi but with a different extension.

Change the automatic name and path of FPGA bitfiles from:

.\FPGA Bitfiles\ProjectName.lvprog_TargetName_ViName.vi.lvbitx

to

.\ViName.vi.lvbitx

 

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.

Compiling can take long and it would be cool to get updates via sms or email at various stages of the compiling process.

 

 

It would be nice to have "time unit converters" in the Labview FPGA Timing menu.

 

My need would be, to automatically, convert Ticks to µs, according to the local Clock cycle frequency ...

 

• Ticks -> µs
• µs -> Ticks
• Ticks -> mSec
• mSec -> Ticks

 

Using this kind of automatic converters in place of "manual calculations with constants" would help during code evolution ...

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