LabVIEW FPGA Idea Exchange

Post an idea

Add JTAG access to NI FPGA hardware

Include co-simulation with ISim

Arising from similar requirements as I have posted many moons ago: HERE.... I naively thought putting a terminal in a disable structure would remove it from the FPGA compile. It doesn't.

Years later, I have developed a nice debug interface for my FPGA code which is becoming more and more modular as I refactor it. I have many sub-modules with their own debug interfaces which can be turned on or off from the top-level VI via LVOOP method injection.

The problem is that I can't really compile my entire FPGA VI with ALL debug paths enabled as this just won't fit (It will sometimes compile, but most often not and our FPGA code base is still growing). And this is before I even think about making my debug information more detailed. I would like to be able to easily switch certain aspects of the debug interface on and off as testing requirements change. On the debug interface level I can do this easily by simply not reading the data from the objects being used for the data transfer or simply passing in abstract methods which don't actually do anything and get optimised away. But I'm left with a load of FP controls which are still eating up resources on the FPGA target. I don't want to delete the controls because that leads me to X copies of ever-so-slightly out-of-sync versions of my test VI which quickly becomes a maintenance nightmare. Instead, I want to be able to "easily" reconfigure my test front-panel to only compile the stuff I'm currently actually interested in.

Part of what I would like is the ability to actually define areas of the FP which are enabled, disabled or enabled (and preferably also based on whether simulation is active or not - hence conditional disables for FP). This way, when compiling, the FP elements will actually disappear and full resource savings can be made (as Xilinx is clever enough to optimise away any pointless code LV may stillhave instantiated in VHDL). In addition, the ability to define certain controls as being enabled only when in simulation mode can allow us to have SGL graphs and so on present when needed during debugging.

So, would having conditional disable options for the FP (where controls are shown as greyed out when not available) be of interest to anyone? If this would be an FPGA only thing, I wouldn't shed and tears.

Am I the only one who would use this? hmm. Maybe.

P2P to GPUs

View All (1)

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.

When debugging, I find it useful to have Graphs on my FPs. Mostly for running in simulation mode but sometimes I want to verify that the compiled code behaves the same way.

I currently have to replace all of my Graphs (fed with fixed size arrays) with Arrays since I can't define the FP element to be a fixed size, unlike arrays. This makes debugging a bit more of a pain than it needs to be.

Is it possible to gbet the option to define a Graph as being a fixed size so that this replacement step is unneccessary?

View All (6)

Hello,

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: Module_FGV_DataCapture.vi

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?

Thanks.

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.

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW FPGA Idea Exchange

Add JTAG access to NI FPGA hardware

Include co-simulation with ISim

Conditional Disable options for Front Panels of FPGA VIs

P2P to GPUs

Accurate simulation of FPGA methods, etc. in simulated I/O modes

Fixed size Graphs for Debugging (similar to fixed size Arrays)

Optimized Error-Case with error-code separated cases (see LabVIEW Idea Exchange)

FPGA global variables accesible through Desktop Execution Node

Easy and small FPGA Simulation helpers

Provide VHDL behavioral models of NI standard Flex RIO interface modules