LabVIEW FPGA Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

The Tick Count function in LabVIEW FPGA can represent time periods with tick count accuracy of up to 2^32 clock cycles, that is (using the standard 40 MHz FPGA clock) about 107 seconds.

Sometimes I need to handle longer time spans, and I use this example.

 

I suggest to implement a built-in 64-bit tick counter.

 

 

 

64bittick.png

With availability of fast FlexRIO cards (such as NI 5761) and FPGA framegrabbers (NI 1483, PXIe-1435, NI PCIe-1433 ) data rates of 1GB/s are becoming commonplace.  However, the FPGA Module is limited to communication only with 32-bit LabVIEW. Since, typically you want to store more than 2 seconds of data in RAM,you would like to use 64-bit LabVIEW as your host application.  Unfortunately, this isn't possible yet.

 

While, I can imagine that a full blown 64-bit FPGA Module add on would be pretty difficult to build (and especially test), I believe there is a solid middle ground at this point.  I can imagine, coding and compiling the FPGA in the normal 32-bit LabVIEW environment, and then just using a 64-bit host application to Read/Write front panel controls and to read/write the DMA buffers from the FPGA.  I don't know the details, but this communication protocols could be very low hanging fruit if it's just a simple matter of recompiling a few key pieces for 64-bit operation.

 

Since the data rates passing to and from FPGAs will continue to climb, as well as the prevalence of 64-bit OS, a 64-bit version of FPGA Module is needed in the new feature pipeline.  This should also be kept in mind as other new FPGA Module features and tools are created, as planning for 64-bit compatability now will make the eventual transition to 64-bit much, much easier down the road.

 

User Lorn has found a brilliant tip for *DRASTICALLY* speeding up FPGA compile times under Windows for PCs with the turbo boost feature. What's more, it's extremely simple to implement.

 

Please let's see this in future versions of LabVIEW as standard.

 

http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Multi-core-Compiling/idc-p/2301338#M297

I love using enums because they can often make discrete options much clearer. Example:

enum clarity.PNG

But, at least as of 2017, the below code is going to use fewer resources and propagate faster because LabVIEW is going to use an 8 bit register above instead of the two bits below. 

 

My solution is to allow smaller integer representations of enums (I'd use a U2 in the above case).

 

Ideally the user wouldn't even have to specify the integer size, it could just calculate the minimum at edit time and show the user what it is.

I think it would be useful if LV kept track of device utilization over each compilation. The data could be presented as a graph which might give useful clues to the developer how the project is approaching the limits of the FPGA. Also, I think this data could optionally be stored in the same folder as the bit file so that the developer can review the file history with their source control.

utilization 3.PNG

 

I have several FPGA projects that require significant compile time (up to 1.5 hours), and for that I am thankful to have my compile server running on a separate computer.

 

The issue comes with the seven Pre-Compile steps that occurs before LabVIEW sends to the code to the compiler. On one particular project this action alone can take up to 35 minutes during which time I can do nothing on that machine.

 

I would like to see much of this precompile time moved from the development environment to the compile server. There already exists a mechanism for updating the user with the compile status so those precompile errors could be annunciated in a similar fashion.

 

Get the development system back online as quickly as possible.

We're starting development on an Ultrascale device, KU40 and am missing the option to utilise the DSP48E2 primitive as we have for DSP48 and DSP48E1.

 

Intaris_0-1670929335347.png

 

NXG seemed to have it, but as we all know, NXG is no more.

 

https://www.ni.com/docs/en-US/bundle/labview-nxg-fpga-module-cdl-api-ref/page/dsp48e2.html

 

Can we please have a DSP48E2 primitive for LabVIEW FPGA? I would really like access to the new features supported, including the wider multiplier.

Writeable inputs to FPGA I/O nodes can be left disconnected without any warning (or broken VI indication) from the VI in which the I/O node is used. This can cause some vigorous head-scratching if the missing connection is not immediately obvious as in the screen shot below. For obvious reasons, FPGA controls have no connector assignment or "Recommended, Required, Optional" attribute. In that case, and to avoid playing "Where's Waldo" on the block diagram, I suggest making FPGA I/O node input connections implictly "required", and if not, the VI would be broken. This would be the same behaviour as seen with cluster nodes. 

FPGANode.png

The latest Virtex-7 FPGAs have something like 20 times the computing power of the biggest FPGA supported by LabVIEW FPGA; it would be cool to be able to get those on a FlexRIO card.

 

Other companies make FPGA boards with up to 32 GB of RAM, the biggest FlexRIO has 512 MB; would be cool to have FlexRIO cards with RAM in the gigabytes.

For debugging, using FPGA VIs in interactive mode can be very valuable.  I have, to this day, not been able to find out how LV determines if a bitfile and a VI match.

 

Therefore whenever I click on the run button for a VI, I'm never quite sure if the bitfile will match or not and often have to wait 1-5 minutes before I can resume working with LabVIEW.  This is a very high price to pay for something which I end up cancelling.  I would like very much if the IDE would TELL ME that the bitfile and VI don't match before starting a new compilation and thus wasting my time.

 

This is opposed to a CTRL_Click of the run arrow which explicitly tells the IDE to compile.

When considering options, it's important to see the development and deployment price. Please put the sbRIO prices on the NI website so we can consider it.

When writing LabVIEW code for an FPGA target, the most important considerations are speed and resource usage.  By using the single-cycle timed loop (SCTL), we can increase the speed of the program by allowing more than one operation to complete per clock cycle.  We also decrease resource usage by removing the flip-flops that would be required to store values between clock cycles for the operations in the SCTL.

 

However, there are limitations of the SCTL.  For some operations, it takes significantly less resources to implement something using a for loop rather than a single-cycle timed loop.  With a for loop, one can auto-index a result at the border of the for loop (if the preallocation of arrays option is selected) to obtain a fixed-size array (valid on the FPGA).  Below is the simplest possible example:

 

AutoIndexed For Loop

 

The equivalent with a single-cycle timed loop would be:

 

SCTL

The replace array/subset VI consumes resources proportional to the size of the array.  Depending on the operation being performed, this can increase resource usage such that it is more practical to use a for loop (as shown above).

 

I propose the creation of a single-cycle timed for loop.  Here is a very rough mock-up (MS Paint is not the most adequate of image processing tools... you will get the idea):

 

SCTFL

 

This solves two problems: 1) It allows for the compiler to know how many times to loop will run at compile time.  It also simplifies the UI by letting the user know how many times the loop will run without having to think through a condition.  2) It allows for the more efficient creation of fixed-size arrays through a SCTL (rather than through a for loop).

If I am choosing to offload multiple FPGA compilations to either a local or cloud compile farm, can we not at least do the itnermediate file generation in parallel?  Our current design takes approximately 10-15 minutes to generate intermediate files.  For 5 Cloud compiles, this blocks my IDE for around an hour.

 

Since the file creation processes are independent of each other, why can't we do them in parallel?

Hi, since there an be a queue for compiling FPGA code, it seems natural to me to also be able to make a queue for generating intermediate files.

 

I'm working with 10 build specs. for compilation per project and generating intermediate files for my design takes aprox. 3-4 minutes. This means that I need to sit by my computer for half an hour just waiting and clicking build on every build specification. Sometimes I work with FPGA VI which need to build intermediate files for something like 7-10 minutes, so this is a pain.

 

It would be great if there was a way of just highlighting all build specifications for compilation with shift and just creating the intermediate files for them automatically one by one.

 

Can this be done?

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

 

 

I've searched but can't see anything similar - please add a method for setting the timeout for FPGA nodes. This includes the 'Open FPGA reference' and FPGA IO nodes.

 

If you disconnect a cRIO FPGA (e.g. NI 9148) from the network, it takes 20-30s for the IO node or Open FPGA reference to execute. This is really bad for the user experience as if they try to exit their application in this time it may take half a minute for the application to exit. It also means you may have to wait that length of time to realise that your FPGA has disconnected under most use cases (you can obviously have an external watchdog loop to check that the node is executing in a timely manner)

 

Please allow me to configure the timeouts for these nodes similar to the TCP/UDP or VISA nodes. They are very similar in how they operate to the FPGA nodes (i.e. a hardware device driver which is susceptible to disconnects!) so I don't understand why these have been omitted.

 

I wouldn't mind having to set the timeout as part of opening the FPGA reference and then internally have it use the same timeout for other IO nodes as follows:

2014-09-29_17-16-29.jpg

 

 

The FIFO read looks like an event based node (like a dequeue or wait on occurance) and I think there's a lot of people that assume it's going to use minimal cpu resources while it is waiting for data. I'm wondering if we can have an option that behaved like that. For example, could we have fixed sized FIFO read where the FPGA could trigger an interupt to let the RT side know the data is ready?

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

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.

Capture.PNG

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

 

 

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.