LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to change FPGA IO Pins at compile time without duplicating VIs?

Hello,

 

I have a FPGA logic that uses 4 DIO pins. The VIs that read or write the DIOs are quite far down in the VI-Call hierarchy:

TopLevel.vi->MainLogic.vi->Sub1.vi...->SubN.vi->VI_that_uses_FPGA_IO_Node.vi

 

What I want to do now is to copy & paste the MainLogic.vi so it is reused multiple times in the TopLevel.vi. 

 

TopLevel.vi->MainLogic.vi...
           ->MainLogic.vi...
           ->MainLogic.vi...

 

The problem I have is that all instances of the MainLogic.vi use the same DIO pins. What I want is that the first instance of MainLogic should use DIO0-3, the second instance should use DIO4-7 etc.

 

The DIOs to be used are currently hardcoded in the "VI_that_uses_FPGA_IO_Node.vi". 

 

I see two possibilites to solve this problem:

  1. Draw a configuration wire from the TopLevel.vi to the "VI_that_uses_FPGA_IO_Node.vi" and use a case-structure there to decide which DIO to use. This solution is not very attractive because I have to draw the wire through all the hierarchy levels, producing ugly spaghetti code.
  2. Create a specific "VI_that_uses_FPGA_IO_Node.vi" for each instance of the MainLogic.vi. This would mean that I would have to re-save the entire hierarchy-chain for each instance of MainLogic.vi, thereby creating a maintenance nightmare.

Any ideas?

 

Thank you,

Dirk

0 Kudos
Message 1 of 4
(2,461 Views)

Can you pass the DIO pins to MainLogic.vi from the top level? Something like this:

 

FPGA ref.png

0 Kudos
Message 2 of 4
(2,431 Views)

Yes, I think this might work but it is a variation of the first solution that I proposed. I would have to route the wires from the MainLogic.VI down through the entire call hierarchy and that is something I would like to avoid. 

 

Thanks

Dirk

0 Kudos
Message 3 of 4
(2,428 Views)

I would do a variation of this idea, but instead have a cluster / class called something along the lines of "Hardware Configuration" that gets passed down the call stack. Its only one wire then and lets you add or remove items (more I/O, some I/O configuration, timing etc.) without altering a lot of con planes.

 

Even better, the data for running the digital I/O is contained in a seperate project library / class (take your pick but in this case there is very little overhead in using a class and a lot to gain in terms of enforced encapsulation). The class exposes methods to read or write to the digital I/O and the object is instantiated in your Main.vi with the appropriate confguration of I/O. The object wire is handed down your call stack to your low level VIs which then call the methods on the object (Read, Write etc.). The advantage of this over my previous suggestion is that you can very easily test and re-use this as a component in future projects.

0 Kudos
Message 4 of 4
(2,406 Views)