Time delays using FPGA RLP

[rurwin]

PCI7811R and LabView 8.2, using RLP in Windows2000/RTX.

Part of the VI on the FPGA implements an interface to a memory block: data-in, data-out, address, Read/Write and strobe. There is also a counter that increments after each cycle so the host program can detect the cycle has completed.

A read cycle looks like this:

    count = Bar1->Data_uCount;

    Bar1->Data_uAddress = address;
    Bar1->Data_uWriteNotRead = 0;
    Bar1->Data_uGo = 1;
    Bar1->Data_uGo = 0;

    while (count == Bar1->Data_uCount)
        ;

   return Bar1->Data_uRead & 0xffff;

At or around the while loop, there is a delay in the C code of between 3.5 and 11 microseconds. This is a single delay and it is always present. I need to do over a hundred of these reads in a 5ms time-slot without monopolising the CPU.

The delay appears to also occur for a write, but that is harder to time because I don't wait for completion.

What is the delay, and how can I avoid it?

Edit:- I should make clear that the while loop always executes exactly once - the delay is not that the CPU is busy in the loop.

Message Edited by rurwin on 04-02-2007 06:40 AM

[rurwin]

Bump

I can narrow this delay down to the three assembler instructions that read the counter for the first time. These instructions seem to take several microseconds to execute. The PCI bus is a known bottle-neck, but accesses should be less than a microsecond, whereas I am seeing three to twelve microseconds for this particular access. Does the 7811 insert so many PCI wait states? How should I avoid this?

[Bassett_Hound]

Hi rurwin,

Can you post a stripped down version of your code that exhbits the delay?

Regards,

Steve

[rurwin]

The C code is:

    // Bar1 is a pointer to a structure in the same form as the registers of the FPGA.
    // It is initialised to point to those registers.

    count = Bar1->Data_uCount;

    Bar1->Data_uAddress = (uint32)address;
    Bar1->Data_uWriteNotRead = 0;
    Bar1->Data_uGo = 1;
    Bar1->Data_uGo = 0;

    readcount = Bar1->Data_uCount ;     // This line is enclosed in timing diagnostics

    for (i = 0; (count == readcount) && (i < 4); i++)
        readcount = Bar1->Data_uCount ;

    ret = Bar1->Data_uRead & 0xffff;
    return ret;


The relevant part of the FPGA VI is here: http://i167.photobucket.com/albums/u142/rurwin/MemRead.jpg

The assembler instructions I refered to:

    ;tail end of timing diagnostics. rdtsc reads the CPU tick counter
    rdtsc
    mov    DWORD PTR _tsccalib+4, edx
    mov    DWORD PTR _tsccalib, eax
    popad
    popfd

    ; readcount = Bar1->Data_uCount ;
    mov    eax, DWORD PTR _Bar1
    mov    ecx, DWORD PTR [eax+56]
    mov    DWORD PTR _readcount$[ebp], ecx

    ; top end of timing diagnostics, time recorded is between the two rdtsc instructions.
    pushfd
    pushad
    rdtsc

[rurwin]

I've just increased the FPGA clock speed to 80MHz from 40MHz. The maximum delay reduces to 10us, the minimum and average delays are unchanged.

In the VI you will see that Data Read and Data Count are on the input side of the FIFOs. This is a recent change to see if it made any difference to this problem. It didn't. Previously they were in a similar position on the output side. The Data Time indicator is unused; in its current form it doesn't measure anything useful.

[rurwin]

bump