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
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Having recently attempted to get started with Simulation for debugging my FPGA code I found out that apparently the built-in LV support for native LV testbenches using simulated FPGA is supported only for ModelSim SE.


Failed Simulation FPGA.png


This is a shame since ISim is included with the FPGA toolkit.


If feasible, expanding the functionality to allos co-simulation with ISim would be a rather splendid idea ideed!



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.

0 Kudos



I simulate small FPGA code parts from time to time, and use these while doing it.

There are 2 helpers.


1) Simulation time estimate and progress: Module_SimulationProgress_Caller + Module_SimulationProgress_Popup

Here the idea is to just add the caller VI and it will call and display progress.

It has some "autotune" funtion to not call popup to often, but still update once in a while. It tries to hit around 0.5-1.5 sec in update.

This will minimize time spend on popup after some iterations. It also makes it possible to stop the main sim VI.

The estimator only works if  your code is fairly static.


2) Data collector while running:

Here the idea is to collect data (in fast buffer) while simulating and use it to display while simulating.

It has 5 buffers that can have different number of elements in them, but all have same length.

Then in a "slow" loop I update graphs once every second, then i can abort if i see something wrong.

This is to avoid having graph plotting in highspeed loop or using graph after simulation is run.


3?) Maybe i will add a plot VI that can take data in from the buffer, just to clean up simulation VI, and make it generic.


Can i get some feedback if it is good or not? Any other sugestions are wellcome!

Or how you do your small FPGA simulations?






0 Kudos

Sorry, I post this into the wrong forum.


See my idea/suggestion in "LabVIEW Idea Exchange".

0 Kudos

I love the FPGA Desktop Execution Node. I'd love it even more if I could access global variables from the FPGA VI that is being emulated:


Globals in DEN.png


I normally use globals as opposted to controls and indicators to curve FPGA resource usage in cases where I won't need those values available through the FPGA Interface on the deployed application.

0 Kudos

This has been a huge frustration in my development.  There is no way to debug a Flex RIO + NI1483 FPGA design other than to tweak, compile, and test with actual hardware.  NI should provide a VHDL behavioral simuation of all of their modules so that full end-to-end simulation can be performed using advanced simulators such as ModelSim.  This would facilitate a much more robust FPGA development cycle for their customers who have these types of tools available.


For the NI1483, a VHDL simulation combined with a VHDL Camera Link behavioral model would be even better.  But the CameraLink model could be developed by the customers as it (At least) is a standard or can be gleened from camera manufacturer documentation.