Data has changed after passing through FIFO?

[NablaQuabla]

Dear experts,

I am currently working on a digital triangular shaping using the 7966R FPGA + 5734 AI. I am using LabView 2012 SP1.

Some days ago I have encountered a problem with my FIFOs that I have not been able to solve since. I'd be glad if somebody could point out a solution/ my error.

Short description:

I am writing U16 variables between ~32700-32800 to a U16 configured FIFO. The FIFO output does not coincide with the data I have been writing to the FIFO but is rather bit-shifted or something is added. This problem does not occure if I execute the VI on the dev. PC with simulated input.

What I have done so far:

I am reading all 4 channels of the 5734 inside a SCTL. The data is stored in 4 feedback nodes I am applying a triangular shaping to channel 0 and 1 by using 4 FIFOs that have been prefilled with a predefined number of zeros to serve as buffers. So it's something like (FB = Feedback node):

A I/O 1  --> FB --> FIFO 1 --> FB --> FIFO 2 --> FB --> Do something

A I/O 2  --> FB --> FIFO 3 --> FB --> FIFO 4 --> FB --> Do something

This code shows NO weird behaviour and works as expected.

The Problem:

To reduce the amount of FIFOs needed I then decided to interleave the data and to use only 2 FIFOs instead of 4. You can see the code in the attachment. As you can see I have not really changed anything to the code structure in general.

The input to the FIFO is a U16. All FIFOs are configured to store U16 data.

• The data that I am writing to the FIFO can be seen in channel 0 of the output attachment.
• The output after passing through the two FIFOs can be seen in channel 2 of the same picture.
• The output after passing through the first FIFO (times 2) can be seen in channel 3 of the picture.

It looks like the output is bit-shifted and truncated as it enters Buffer 1. Yet the difference between the input and output is not exactly a factor of 2. I also considered the possibility that the FIFO adds both write operations (CH0 + CH1) but that also does not account for the value of the output.

The FIFOs are all operating normally, i.e. none throws a timeout. I also tried several different orders of reading/writing to the FIFOs and different ways of ensuring this order (i.e. case strucutres, flat and stacked sequence). The FIFOs are also large enough to store the amount of data buffered no matter if I write or read first.

Thank you very much,

Bjorn

[nathand]

Is there any chance you can attach your VI, not just the screenshot? I cannot follow the logic here and don't understand why you would be doing what you're doing, but the full VI might help explain. Why are you writing to the FIFO only when the Read does not time out? What happens on the first cycle, when there is nothing to read so it does time out?

Why are you trying to limit the number of FIFOs? How are they implemented?

What's the point of the CH0-PT FIFO?

[NablaQuabla]

Please see my attached project folder. The VI of concern is the FPGA.vi.

The program is intended to monitor channel 0 and channel 1. Those channels get shaped using a triangular shaping filter. As soon as one of these shaped traces exceeds a certain threshold I am capturing 400us traces for all four channels.

The Buffer 1 and Buffer 2 are there to store data until I need it again to iterate the next value of the shaped traces. They are being filled with ~125 zeros before I switch to the code shown above (using a case strucure). So I know that there are values in there. Yet as I said I initially tried the whole setup using sequence structures but these produced the same problem. This is just one of the versions of code where I tried to fix the bug but simply failed. No FIFO ever shows a time out. I monitored them seperately when I used the squence structure and everything is fine BUT the output.

All CHX-PT labeled FIFOs are there to allow the capturing of a ~350us long pre-trace. They are also initially filled with 16000 zeros. We need such a long pre-trace to get information about the stability and credability of pulses. They are still working properly.

The 7966R allows a total of 16 FIFOs as far as I know. I am right now (in the working version) using:

 - 4 x Buffer for the shaping

 - 4 x Pre trace buffer

 - 5 x FPGA to Host interfaces (4 for the channels and 1 that gives status information for each trigger)

So right now I am using a total of 13 FIFOs. Yet I need to implement a second shaping in the same code using a different shaping time (= number of samples in the buffers). Using my old approach I'd need 4 more FIFOs. But I only have 3 more left...

So I decided to interleave some of my channels to use only one FIFO. I have plenty of time left within each SCTL iteration so that multiple read and write commands for one FIFO should not be a problem. Could this be the problem that I am reading twice from a FIFO within a single iteration of the SCTL and this is not supported?

All FIFOs are 'never arbitrate' for read and write so I use sequence structures to ensure order.

If this problem persists I'm considering using memory nodes to create a circular buffer. But they are also limited to 16. So it doesn't really solve the problem.

Thanks,

Bjorn

[nathand]

Unfortunately I don't have the time to work through what you're doing in this code. I can offer a couple of debugging suggestions:

- Replace the analog input reads with constants, and see what the output is

- Run in simulation (on the development machine, instead of on the FPGA)

- Replace the FIFOs with standard LabVIEW queues and run it on your development machine (in the Windows target) to check the logic

- Simplify and see if the problem still occurs

[NablaQuabla]

During the last couple of days I tried the following:

1. Running the FPGA code on the development PC with simulated I/O. The behavior was normal, i.e. like I've intended the code to perform.

2. I tested the code on the development PC with the square and sine wave generation VI as 'simulated' I/O. The code performed normal.

3. I replaced the FIFOs with queues and ran my logic on the dev. PC. The logic performed totally normal.

4. Right now the code is compiling with constants as inputs like you suggested...

I am currently trying to get LabView 2013 on the development machine. It seems like my last real hope is that the issue is a bug in the XILINX 13.4 compiler tools and that the 14.4 tools will just make it disappear...

Nevertheless I am still open for suggestions. Some additional info about my FIFOs of concerne:

Buffer 1 and 2:

- Type: Target Scoped

- Elements Requested: 1023

- Implementation: Block Memory

- Control Logic: Target Optimal

- Data Type: U16

- Arbitrate for Read: Never Arbitrate

- No. Elements Per Read: 1

- Arbitrate for Write: Never Arbitrate

- No. Elements Per Write: 1

The inputs from the NI 5734 are U16 so I am wirering the right data type to the FIFOs. I also don't have any coercion dots within my FPGA VI. And so far it has only occured after the VI has been compiled onto the FPGA. Could some of the FIFOs/block memory be corrupted because we have written stuff onto the FPGA too often?

[Intaris]

The 16 FIFO limit is only for DMA FIFOs, for communicating with a host program.

You can have plenty more Target-based FIFOs (you'll eventually fill up your chip).

Don't interleave like this, the interleaving may end up costing more resources than simply duplicating the FIFOs, not to mention bugs.

[T-REX$]

First off: forgive me for not looking through your attached code yet...

Do you have a FIFO R/W in an SCTL timed by the External Clock input?

I would also suggest making sure the CLIP versions are the same between the two LV versions. You may be able to get away with using just the newer FAM support instead of a whole new LV version.

[NablaQuabla]

Thanks for the input. The FIFO R/W is not in an SCTL using an external clock. I'm using a derived clock from the internal 40 MHz.. So the problem shouldn't be there.

If the 16 FIFO limit only applies to DMA FIFOs I don't need to interleave data. So I'll just go back to my old VI and add 4 additional FIFOs. So no need to read through my code. Maybe I'll try to tackle the problem in the future just out of curiosity but as there is no need right now I'll move on.

Thanks again!