LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Possible Data Corruption in DRAM NI7931

Hi ,

Im using a DRAM to write data into from the host and then send read it and send byte by byte.

Im using dma to read the data from the HOST PC and the from the DMA to the DRAM , and at the end from DRAM to fifo.

When I read the data , in the target side , it seems the first byte of the sent data , is different .

Is there any methods , to read the data directly from the DRAM , in order to be sure that the read from the DMA into the DRAM is working fine ?

or are there any other known methods to debug the DRAM ?

 

Thank You.

0 Kudos
Message 1 of 6
(896 Views)

There is no way to read directly from DRAM.

 

Are you using simulation mode?  See http://zone.ni.com/reference/en-XX/help/371599N-01/lvfpgahelp/running_fpga_vi_on_emulator/ This can help troubleshoot.

 

Can you post your code?

 

My suggestion is to make a pass-through where data goes Host->DMA->FPGA->DMA->Host; this will confirm that the DMA setup is right.

 

DRAM needs multiple cycles to return data


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
LabVIEW Programming (make LV more popular, read this)

LabVIEW FPGA for High Throughput Applications | VI Week 2020
0 Kudos
Message 2 of 6
(870 Views)

Hi, thank you for reply.

No , im not using the simulation mode because , the addresses is coming from another external device tha it connected to the adapter. I cant simulate this adrresses.

After initial debug i concluded that the data stored in the DRAM is fine . I'm suspecting the the issue is between the DRAM and the FIFO , and from the FIFO outside . It seems that maybe the FIFO is not empty and have some junk before the first read.

Each time im reading one data from the DRAM to the FIFO , and from the FIFO sending it out.

When the DATA is trasnmitted , i see that all the data is transmitted but with another one byte in the begging , and when i'm calculating CRC , the CRC isnt correct because of that one first byte.

 

Thank You.

0 Kudos
Message 3 of 6
(862 Views)

I understand that about the outside address. It sounds however that something much more fundamental is at stake here. If handshaking or timeout signals are connected properly only valid data should ever be read. 

 

I recommend simplifying into one or more test cases to get all the components figured out with the help of simulation mode. Then you can put it all together with higher confidence.

 

Many projects have parts that do not simulate but it is always recommended that a way to simulate parts is found. Otherwise the project will take longer than it should.

 


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
LabVIEW Programming (make LV more popular, read this)

LabVIEW FPGA for High Throughput Applications | VI Week 2020
0 Kudos
Message 4 of 6
(857 Views)

Hi , thank you for your reply and help.

at first i've used an TimedOut Handshake between the DRAM and the FIFO , now i modified it to Handshaking ("Ready For Input") , but still didnt compile it. im including a two images which shows the implementation .

do you think that the handshaking method could have an impact on it ?

maybe, should i clear the fifo one state earlier ?

Thank you.

 

Download All
0 Kudos
Message 5 of 6
(855 Views)

I would go with the handshaking approach and without the select function.

 

Check out this example C:\Program Files (x86)\National Instruments\LabVIEW 2017\examples\FlexRIO\Coprocessor Modules\PXIe-791X\PXIe-791X Getting Started\PXIe-791X Getting Started.lvproj

 

Even though it is not for your hardware it demonstrates some very good concepts.

 


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
LabVIEW Programming (make LV more popular, read this)

LabVIEW FPGA for High Throughput Applications | VI Week 2020
0 Kudos
Message 6 of 6
(847 Views)