FPGA code and DLL, is there anything I should take in to consideration?

[kaêm]

Hi,

We might start using one of the R-series DAQ card which requires FPGA programming. After reading the basics of LV FPGA programming, I have understood that I'll need to make a FPGA program that is loaded to the hardware and then an interface VIs that will communicate with the FPGA code. Is there any limitations on putting these interface VIs into a DLL and calling them from external applications? Is there something else I should know about before even thinking about doing this?

Thanks.

[Wiebe@CARYA]

That should work without problems. Never done it though.

As a recommendation, I'd suggest to try it out once with a simple test VI,
then use a LabVIEW program to do the development. When done, make a dll
again. Working with dll's during testing will be very time consuming. You
need to close the program that uses the dll every time you want to rebuild
it, and this gets annoying very fast.

If your decision depends on this functionality, someone here could try it
out. What LV version do you consider to use?

Regards,

Wiebe.

[kaêm]

Thanks Wiebe for your reply.

We currently have LV 6.1, 8.2 and 8.5, We'll propably be using the 8.5 version(or a newer version when it comes out) for the development.
The 6.1 is out of the question, at least that is sure.

It's crucial for the project to know if a DLL can be used with FPGA like this, so if someone has a bit of spare time to do a simple experiment,
I would appreciate it a lot.

Thanks.

[Wiebe@CARYA]

I'd use 8.5, it has some benefits. They added fixed point floating numbers,
and you can create subvi's with references to inputs/iouputs. Our system
uses several loops with the same functionallity, and we had to copy all the
subvi's for each loop (and had to fix mistakes 5 times)... Also, in 8.5 you
can run simulations of the FPGA vi's, to spot the most obvious mistakes. In
8.2, you find out after 15-60 minutes compile time.

The system left our office, so I can't give it a try.

Regards,

Wiebe.

[kaêm]

Thanks Wiebe.

I'll stress on the point on using LV 8.5 when (and if) the FPGA development starts.

[John J]

I have been using a setup where we were required to adapt a simulation in FORTRAN to control an R Seriies card using LV 8.2 for a hardware-in-the-loop system.  I created a C DLL which is callable from both FORTRAN and LabVIEW.  From the FORTRAN it starts LV as a separate process, and creates a shared memory space for passing data.  It uses standard windows events for process synchronization and the FPGA interrupt for FPGA to host synchronization.  The LabVIEW code is only one host VI and a single multi-tasking FPGA VI.

The only hitches were a minor bug in the LV FPGA 8.2 interrupt handling which has since been fixed, and the fact that windows is not a real-time operating system.  I did not have the money for a true real-time system.  However, by optimizing windows I was able to pull of a 100Hz simulation rate with only extremely rare missed updates.

In most cases there is not a need to start a separate LV process, but it worked great for us without a ton of effort.

[kaêm]

Thanks John.

I guess that if it worked with a C DLL, there shouldn't be any problems with a LV DLL either.

[John J]

Yes, my situation is backwards from yours.

While I beleive it will work, LabVIEW is a little "odd" in the way it handles FPGA VI executions.  This only makes sence, since it is not just another windows execution.

It would be "a good thing"  to hear from soneone who has done it before to find out if there are any "nice to know" things before you start.

JJJ

[kaêm]

OK. I understood that you have made the FPGA DLL with CVI.

Waiting for a comment from someone who has done a DLL that communicates with FPGA code.

[John J]

For clarification:

In my case an Absoft FORTRAN executable uses my (MS Visual) C DLL that handles the interprocess communication.

The DLL starts a separate LabVIEW host VI process that uses the same DLL to communicate back to the FORTRAN, and uses an FPGA VI running on the R Series card to talk to the hardware.