DRAM : data corruption @ 100MHz

[CyGa]

Hi,

According to answers get from NI support, I'm using the DRAM NI Memory Interface to write/read data @ 100MHz. The FPGA code is designed to fit on a PXIe-7962R FPGA board.

As you can see in the code attached, I first write all data blocks I'll use with default values :

• Lower 64 bits = 0
• Upper 64 bits = 0

Then, every 8 loops, I'm incrementing 2 different counters. One counter starts at 0, and is used to be stored in 'Lower 64 bits'. The other one starts to 1, and is used to fill 'Upper 64 bits'. In this example, the first 1000 pts are sent into DMA (FIFO - Debug) for debug purposes.

Then, once when all requested loops are done, I read data stored in the DRAM from address 0 to 'n-1 loops'. For each address, I first get the 'Upper 64 bits' and send them in the DMA (DMA_ToHost), then 'Lower 64 bits' and place them in the DMA (DMA_ToHost).

So I should have, on the host side, getting data from DMA_ToHost :

1. value = 2 (upper 64 bits ; DRAM address 0)
2. value =1 (lower 64 bits; DRAM address 0)
3. value =3 (upper 64 bits ; DRAM address 1)
4. value =2 (lower 64 bits; DRAM address 1)
5. value =4 (upper 64 bits ; DRAM address 2)
6. value =3 (lower 64 bits; DRAM address 2)
7. ...

Doing this test, after #30-50 samples (varies through executions) read from the DRAM, things change and I get things like this :

29. value = 16 (upper 64 bits ; DRAM address 14)

30. value = 16 (lower 64 bits ; DRAM address 14) !! instead of value = 15

31. value = 17 (upper 64 bits ; DRAM address 15)

32. value = 17 (lower 64 bits ; DRAM address 15) !! instead of value = 16

...

=> It looks like there a shift in the adress read...

Am I missing something in my code or is there a bug somewhere ?

[tannerite]

Hi zyl7,

I have found a KnowledgeBase article that could be relevant to what you are noticing which could be due to a data integrity issue. Please give this article a read and see if this pertains to your situation. It would be helpful to know what versions of our software you have installed and are currently using as well.

Best,

tannerite

[CyGa]

Hi Tannerite,

Thank you for your answer !

I looked at the KB and decided to download the VI which allows checking if the patch is installed or not on the machine : it says that it's not installed.

So I decided to install the patch but it says that I already have a 'Higher version of NI LV 2011 FPGA Digital Designs'...

How do I resolve this ?!

[tannerite]

zyl7,

Using our NI Update Service you can configure your system to periodically check for updates. This will allow you to have the most up-to-date patches and updates for National Instruments software.

Best,

tannerite

[CyGa]

Hi Tannerite,

As you can see on attached pic, the 'NI Update Service' doesn't show any updates about LV FPGA 2011 module.

So I guess my computer is up-to-date. Nevertheless, the VI allowing to cjeck this (cf. link on the KB you adviced on your previous post) says that the patch isn't installed on my computer, and running the installer gives the resulted exposed in my previous post.

So what's next ? Does this DRAM corruption really comes from my software package ?

Below is my system description :

Système d'exploitation (OS) Windows 7 Professional
Version de l'OS 6.01.7601
Infos OS Service Pack 1
Processeur Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz / Intel64 Family 6 Model 42 Stepping 7 / GenuineIntel / 2693 MHz
Nombre de processeurs 4
Mémoire physique 7,95 Go de RAM

Logiciels National Instruments : Version :

CVI Run-Time 10.0.1.434
NI-DAQmx Device Driver 9.5.0f2
NI-DAQmx ADE Support 9.5.0
NI-DAQmx MAX Configuration 9.5.0
NI Script Editor 1.3.2
NI-DMM 3.0.4
DMM Soft Front Panel 3.0.4
NI-FGEN 2.7.4
FGEN Soft Front Panel 2.7
FieldPoint 6.0.10
LabVIEW Interface 6.0.10
NI-488.2 Software 3.1.0
NI I/O Trace 3.0.2f0
IVI Compliance Package 4.4
LabVIEW Run-Time 2010 SP1 10.0.1
LabVIEW Run-Time 2009 SP1 (64-bit) 9.0.1
Measurement & Automation Explorer 5.3.3f2
Measurement Studio Visual Studio 2005 Support - See individual versions below.
DotNET
Common 9.1.20.163
NI-USI 1.9.1.4681
NI-DCPower 1.4.1
NI-DCPower Soft Front Panel 1.4
NI-HSDIO 1.7.4.3
NI-HWS 1.4.8
NI PXI Platform Services 3.2.0
NI-RFSA 2.3.2
NI-RFSA Soft Front Panel 2.3
NI-RFSG 1.6.4
NI-RIO 4.1.0
CompactRIO 4.1.0
CompactRIO Module Software 4.1.0
R Series 4.1.0
NI FlexRIO 2.2.0f2
NI-Sync 3.3.0
NI-PAL Software 2.9.0
NI-SCOPE 3.6.2f1
SCOPE Soft Front Panel 3.0.0
NI-Serial Software 3.9.0
LabVIEW SignalExpress 5.0
NI-SWITCH 4.5.0f1
Soft Front Panel 4.5.0.49153
Switch Executive 3.50.49154
NI System Configuration 5.3.3f0
NI-TClk 1.8.1
NI TestStand 4.5.1
NI-VISA 5.2
NiVisaServer.exe 5.2.0.49152
NIvisaic.exe 5.1.2.49152
NI-VISA Runtime 5.2
DIAdem 2011 11.3.0.4563
LabVIEW 11.0.1
Database Connectivity Toolkit 11.0.0
FPGA 11.0.1
Internet Toolkit 11.0.0
Real-Time 11.0.1
Real-Time Execution Trace Toolkit - LabVIEW Support 2.0.4
Report Generation Toolkit For Microsoft Office 11.0.0
LabVIEW Run-Time 2011 SP1 f2 11.0.1
LabVIEW Run-Time 8.2.1 8.2.1
LabVIEW Run-Time 8.5.1 8.5.1
LabVIEW Run-Time 8.6.1 8.6.1
LabVIEW Run-Time 2009 SP1 9.0.1

[tannerite]

Hi zyl7,

It looks like you have LabVIEW 2011 FPGA Module SP1 which includes the possible DRAM corruption bug that the f1 patch did. The f1 patch is for the non SP1 version of the FPGA Module. So, it looks like you are currently up-to-date.

As for the original question, it appears that you are not using the “Input Valid” functionality of the DRAM node. You have a TRUE constant wired to the Input Valid terminal. This will not ensure data integrity. I see you are checking the “Ready for Input” to check if the DRAM is full but you are not using these two for the intended purpose of hand shaking. The Memory Throughput Test located in the Example Finder by navigating to:  Hardware Input and Output » FlexRIO » External Memory » Memory Throughput Test. This example is a good implementation of proper handshaking to ensure that data gets written and read only when there is valid data ready. I would recommend looking through this example and fitting this example to your project.

Best,

tannerite

[CyGa]

Hi Tannerite,

Input Valid is a flag used to discard element insertion in the RAM. The documentation says : "Wire the output valid output of an upstream node to this input to transfer data from the upstream node to this node." So if you are just pushing values that are always correct, then Input Valid can be set always to true.

My data comes from a counter, so data is always valid.

However you may have noticed that I stop the 'Write DRAM' loop as soon as the "Ready for Input" flag is set to False. That way I know that something went wrong when writing data @100MHz. Indeed the documentation says "Returns TRUE if this node is ready to accept new input data. Use a Feedback Node to wire this output to the ready for output input of an upstream node.".

This flag never rises up in my example.

In my process I can't loose any data or repeat DRAM writing, that's why so as soon as the "Ready for Input" flag becomes False. This mecanism also allows to bench if the write process of the DRAM supports well the speed of 100MHz.

I think the focus as to be made on the Read process... I still consider there is a data corruption in the DRAM write/read process.

[tannerite]

zyl7,

I have looked over the logic of your code and mapped the variable for several iterations and I see what you are speaking. I also see what you are saying with always have the ready tied to TRUE since you are not waiting on any data upstream. This is odd behavior because I cannot see any paths in your code where the upper and lower bytes can write, or read, the same value for one address. I am still looking into this issue further and analyzing the code but here are a few things to try:

1. If you run this code using the 40MHz clock instead of the 100MHz clock, do you experience the same behavior?

2. Can you change the Maximum Outstanding Requests for the DRAM to something larger than 32? Do you see any different behavior? Does the issue still occur at the 30-50 iteration mark?

3. Show the Error Terminals on all of the DRAM methods and latch if the Boolean value portion of the error cluster is ever true. It is possible that an error is occurring and not being displayed.

Also, how are you monitoring the data to notice this behavior? Are you using the Debug FIFO or the DMA_ToHost FIFO and logging it on the host?

-tannerite

[CyGa]

1. If you run this code using the 40MHz clock instead of the 100MHz clock, do you experience the same behavior?

No, if I remember well @40MHz it works fine.

2. Can you change the Maximum Outstanding Requests for the DRAM to something larger than 32? Do you see any different behavior? Does the issue still occur at the 30-50 iteration mark?

I experienced this behaviour when working for a customer. I do not have the hardawre anymore and cannot achive some more tests.

3. Show the Error Terminals on all of the DRAM methods and latch if the Boolean value portion of the error cluster is ever true. It is possible that an error is occurring and not being displayed.

I experienced this behaviour when working for a customer. I do not have the hardawre anymore and cannot achive some more tests.

Also, how are you monitoring the data to notice this behavior? Are you using the Debug FIFO or the DMA_ToHost FIFO and logging it on the host?

I'm using the Debug FIFO to get the first 1000 samples written in the DRAM in the host. These samples are simply stored in an array on my host front panel.I then compare them to data get from ToHost FIFO.

 This is odd behavior because I cannot see any paths in your code where the upper and lower bytes can write, or read, the same value for one address.

I don't understand your comment. The code is designed to insert in 'lower byte' and 'upper byte' values coming from two ounters. One counter starts with value 0 and the other with value 1. So it's normal that for one adress 'upper byte' and 'lower byte' are not them same, there should be a difference of 1 between their respective values.

The problem is that after reading #30 adresses, 'upper byte' and 'lower byte' contains the same value ! It never should be ! 

[tannerite]

zyl7,

I see what you are saying, I walked through your code and have attached what the first 16 iterations should look like. Without monitoring the timeout of the DMA_ToHost function, there is no guarantee that the data gets transferred across the DMA complete and ordered. It looks like the most error prone part of the code is transferring data via DMA; especially since you are transferring at 100Mhz.

Best,

tannerite