09-21-2011 06:14 AM
I'm currently on a project which has historically bee based around a PCI backplane (in a desktop PC) containing a couple of PCI-6229 cards and a PCI-7833R. This forms the core of a testrig of which there are about 25 instances worldwide. In addition, we also support many rigs which are cored around a NI PXI chassis.
There is a drive to replace the PCs and we have opted for a for smaller footprint unit having fewer PCI slots. These are being equipped with an MXI extender card to a PXI backplane. This means in future, we need only keeps spares in the PXI format. Supporting two sets of backplanes containing near-identical hardware without implementing two near-identical pieces of software does present its problems: The FPGA bitmap build for the PCI version of the card will not open through the reference type for the PXI version of the card. We need to have a PCI and a PXI version of the bitmap. Irritatingly, the source code for these two is identical.
The first part of the solution is to establish which backplane we're using. This is straightforward. Supplying the VISA Find Resource function with the appropriate search string will identify if any PXI backplanes are connected. (Figure 1.)
Next, we need to maintain references to both FPGA VIs. Figure 2 illustrates how the FPGA to be used can be opened and proposes a structure in which the references to all available FPGA types (this example actually has four FPGA bitmaps which might be selected). In each of the other cases, the appropriate bitmap is selected in the Open FPGA Reference VI. Further, in each case, the reference is wired to the appropriate component from the cluster. (For calibration records, we also find it necessary to return the serial number of the card, but that portion of this code can be ignored.) Notice that the FPGA_Type component of the cluster is used to control which bitmap loads and which Ref component is used to store its Reference. This is necessary because the reference types are different for each bitmap.
Having set FPGA_Type, Figure 3 shows how to employ the selected resource. A separate Read/Write Control must be coded for each FPGA type.
Closing the resource also requires a case for each FPGA type.
I hope anyone else planning a stepped migration between backplanes can make use of this.