Using viMoveInX in PCI

[davelclark]

For a PCI transaction, does viMoveInX pay attention to the VI_ATTR_SRC_ACCESS_PRIV and VI_ATTR_DEST_ACCESS_PRIV attributes? If VI_ATTR_SRC_ACCESS_PRIV is set to VI_DATA_PRIV does viMoveInX break the access up into individual accesses like it would in VXI or does it read the entire block of data in a single PCI frame?

The reason I ask:
I'm reading a block of data (~2Kbyte) from a 3rd party PXI device using 2 methods. 1) I use viMoveIn8(). 2) I use viIn8() in a loop. The first method works fine, the second one results in a few byte of corrupt data at random places in the block. The problem is most likely the PXI device. I'm just trying to get as much info into what is going on as possible.

Thanks,
David Clark
Software Design Engineer

C&H Technologies, Inc.

[Dan_Mondrik]

Does viMove* pay attention to *_ACCESS_PRIV? No, those attributes are not defined for PXI/PCI. Do those operations pay attention to *_INCREMENT? Yes, you can choose FIFO or incrementing. (I know that's not the specific question you asked, but it helps for the analogy.)

If the *_INCREMENT is set to 1, VISA will perform the sequential accesses as fast as it can. We have no control over how many PCI frames that happens in. That's at least 2 levels beneath us, even if we wrote this in assembly. The PCI bus manager (eg, somewhere between the CPU, MMU, and BIOS) handles things like bursting and retries.

If the *_INCREMENT is set to 0, VISA will do the specified number of cycles at the same address. This is inherently somewhat slower than incrementin
g addresses, especially when the MMU realizes it can't cache the previous value it read from that address. So this by nature is slower and I can't imagine viMove* in FIFO mode on PXI/PCI ever having multiple accesses in the same PCI frame.

The results of viMoveIn* and multiple calls to viIn* should not vary, assuming the data being read is not volatile. If they do, there's a problem somewhere. I agree with your guess that it's the device. Do you have a PCI bus analyzer to see what's going on?

Dan Mondrik
National Instruments

[davelclark]

Thanks for the response Dan.

It turned out to be an issue with the device and the speed at which I perform the accesses. viMoveIn works fine. viPeek in a loop also works. viIn in a loop does not work. If I put a little bit of code (i.e. short for loop) between viPeek's in a loop it does not work. I asssume there is more software overhead in the viIn than the viPeek and that is the difference. Regardless, that is probably more info than you need or want. I'm in contact with the 3rd party to let them know of the issue.

Thanks again for answering my question.

Dave