LabVIEW FPGA Idea Exchange

Post an idea

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.

View All (2)

FIFO read that doesn't use 100% CPU

View All (1)

The document High Performance FPGA Devleoper's guide lists a parallelized bubble sort. I tried this out, and found that it actually doesn't work. This this matrix successfully gets the max value on top, and the minimum value on the bottom, it doesn't completely sort the values between.

Bubble Sort.JPG

In this example, if the highest value started at the end of the array (red), and the 2nd highest value started 2nd from the end (pink), the high value ends up at the top, and the 2nd highest value ends up 3rd from the top.

Bubble Sort - Markup.JPG

This lattice can be completed to sort the middle sections by adding 3 more columns, one with 3 Min/Max blocks comparing the center 6 values, one with 3 Min/Max blocks comparing the center 4, and a final Min/Max operation comparing the middle 2. This will complete the sort, but will take 7 sequential steps instead of the 4 listed. The following works to sort the entire array:

Bubble Sort - Corrected.JPG

Link Wire label to Data format

I have recently started placing wire labels in my code to keep track of datatypes of wires flowing around my code. This is very useful to understand what is going on on the FPGA since not all grey wires (FXP) are equal and slight mismatches can mean big trouble in the code.

As such I tend to label wires like "Phase FXP+25,0" and so on.

What I'd love to be able to do is to place a formatter in a Wire Label to be able to keep such labels up to date because at the moment it's probably more error prone than anything else due to some wires and labels not being synced any more due to code changes or bugfixes.

If I can set a wire label to "Phase %s" or similar to place the ACTUAL datatype in the label this would be amazing.

FPGA FIFO and Memory Editor

I have been working with FPGA for quite a while, and realized that manually opening and editing DMA, Target Scoped, P2P, VI scoped Memories, and project scoped memories can be very tedious and time consuming. Wouldn't it be great if there was a way to edit FPGA FIFOs and Memories from a single place. This notion gave birth to the FPGA FIFO Editor and FPGA Memory Editor. These editors would give the ability to see, create, remove, and edit FIFOs or Memories for that specific project (list both project and VI scoped items). Furthermore, their could be some additional logic built into the Editor that would alert the user when they have tried to configure something incorrectly (for instance an R Series target only has 3 DMA FIFOs, alert the user when they have configured more than that).

Listed below is a mock-up of the FPGA FIFO Editor.

View All (1)

View All (6)

Include co-simulation with ISim

Default data type Fixed Point (FXP)

View All (7)

Pipeline structure

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.

View All (6)

Basic building blocks

Along the same line of thinking as this idea:

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Handle-Fixed-Point-Integers-Going-Into-Case-Structures/idi-p/3360844

It would be cool if we got rid of the coercion dot here for smaller integers and integer fixed point numbers as the index for an array.

Smaller integer representation for indexes2.png

As it is, it's hard to tell if the compiler will use the bigger I32 for this.

This behavior would also useful for other integer inputs like the memory address input.

In labview it is not allowed to exit SCTL running in an external clock domain. Labview claims it could lead to instability of code due to glitches etc on the external clock.

I propose to leave the option open to the programmer to take that risk, which is not always there. It can lead to better understandable code.

For example I have code where I read data from an NI5752 ADC module and store in in block RAM (32 ADc channels, 32 block RAMs). Reading from that ADC implies acquiring the data in the external ADC clock domain. So, also the writing to memory is in that clock domain.

I needed to implement a function to reset the memory as well. That means writing to that memory. That has to be done in an SCTL in the same external clock domain.

However, this reset function (subVI) can no be inserted in the normal "enable chain" of the main program, since the SCTL can not be terminated and the memory reset subVI never terminates.

Now I had to make an ugly trick to get this done. In the main program I create a dead branch doing the reset. That subVI never stops, but after the reset has been done it send a signal via a FIFO to the "wait reset" subVI in the main enable chain. the wait reset is running in the default clock domain and can exit the wait loop after the reset signal has been received.

However, this trick is not easy to understand from the program. It would have been easier if the reset function (external clocked loop) could have exited by itself and be inserted in the main enable chain. That would have been more logical..

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.

Derived clock instantiation

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.

On the cRIO-9068, the third serial port and the second Ethernet adapter is actually mounted on the FPGA, resources are consumed to redirect to realtime. Currently there are no access to this resource on the FPGA for developers, only from the Realtime.

I would like some I/O Nodes for interacting with these devices on the FPGA. NI could put up some examples how they could be used.

Today the resources are invisible to the developer, except for the additional long compile time and resources used (about 7%).

I attached pictures of the FPGA design and the resources consumed for a blank vi.

Sincerly,

Jens Eriksen

View All (4)

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)

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.

FPGA Graph handling

I've developed a small test utility for testing FPGA code on my windows machine before proper FPGA testing and have noticed something I think could be improved.

If I have a graph or any other indicator with DBL default data type within a conditional disable, the compiler still throws an error regarding an unknown state (DBL). Although the terminal is in the diagram disable, the object seems to remain on the FP (but also in the code being sent to the FPGA compiler).

Can we actually remove the graph (or other culprit control) in the background before starting the actual compile so that I don't need to drop and re-connect every time I want to switch execution systems?

Shane.

Improve Compile Retrieval Process

Long compile times are a necessary evil of FPGA code. Even with the vast improvements of Vivado, compile time still ranks as the biggest killer of large project efficiency. As compile times approach 3-4 hours, their successful completion becomes paramount. All too often I find that the Xilinx compiler running on the compile worker has completed successfully however some small communication glitch either between my development machine and the farmer or the farmer and the worker has caused the compile to be lost. It is quite frustrating to know you have a completed bitfile from Xilinx but the NI tools will not perform the final processing steps required to create the lvbitx file. The only solution is to restart the compile costing another 3-4 hours of productivity.

Typical workflow in our company for these large projects is to spend mornings testing and stressing the compile(s) from overnight. Then make any bug fixes and incremental feature improvements and try to start a compile by mid-morning. By mid-afternoon when the compile is complete do the process again so that you can process another build for overnight. If one of the compiles fails because of timing or resource problems, there's nothing that can be done. But if it fails because of glitches in NI's compile wrapper code, that becomes a waste of a half of a day of productivity.

I propose that the current methods for compiling bitfiles be modified. The goal is to improve user productivity. Some of my suggestions include:

For a given build specification, give it the ability to re-attempt to retrieve the last completed compile. This option would be available even if the VI's that created that compile had been modified.
If a compile was completed previously for this build specification and there has yet to be a successful lvbitx generation, prompt the user before doing anything that would destroy the ability to retrieve it.
Make sure that all of this still works when changing connections to the worker. For example if I start my compile at work then take my laptop home and want to login to my VPN at night to check on my compile
Don't remove any chance to get a compile if there was a communication error. Right now when I get the communication error, I see a red X in the compilation status and my only option is to remove it from the list.

View All (2)

LabVIEW FPGA Idea Exchange

Multi top clock, for main VI ... Multi partition FPGA code ...

FIFO read that doesn't use 100% CPU

Math Error in Lattice Bubble Sort in High-Performance FPGA Developer's Guide 1.1

Link Wire label to Data format

FPGA FIFO and Memory Editor

Drive a host timed loop with LabVIEW FPGA IRQ

Include co-simulation with ISim

Default data type Fixed Point (FXP)

Pipeline structure

Basic building blocks

Allow Select Node to Invert Select Terminal

Get rid of coercion dot when using a smaller integer for index

Externally clocked Timed loops : Allow exit

Conditional Disable options for Front Panels of FPGA VIs

Derived clock instantiation

Access to serial and ethernet port in FPGA for cRIO-9068

Improved Search Scope for IO and Memory X-Nodes

Allows locking of parts of the block diagram to minimize compile time

FPGA Graph handling

Improve Compile Retrieval Process