DDR issues on Zybo-Z7-20

[ArKay99]

I've been working with my Zybo-Z7-20 board for about 6 weeks now and have been having a hard time with anything having to do with the DDR. If I built and run the OOB demo using Vivado 2016.4 It ran, sort of. I would sometimes get could not write to memory 0x0010000 errors when trying to load a new change into the memory. When I tried to run the demo in Vivado 2018.2, it would give the same message, but none of my breakpoints would get hit and the program in flash would only run. If I set the linker file to run from OCM it would run, but not that well. I built the Hello World example and it ran fine. I then set the Hello World example to run from OCM and did some read write tests to DDR and they worked. Then I built and ran the memory test example and tested the DDR and it ran fine. Then I put the memory test code into the OOB demo main program, set it to run from OCM and it failed to read or write to memory.

Then I started looking at physical memory. On my board (I have a B2 version) there are mounted 2 Zentel A3T4GF40ABF chips. I downloaded the manual and found a few things about them. They are DDR3L @ 1600K. The schematic shows a MT41K256M16HA-125 which is a DDR3L @1066F. The other parameters are fairly close and in the Zentel part manual it states the part can be used as a 1066 speed bin part. I thought I had found the answer to my stalled DDR, but entering a few of the parameters that were slightly different in the Zynq IP setup page didn't help.

Today I gave up on trying to make the 2016.4 demo work in 2018.2 and decided to work with and build the Audio DMA example. After I got it dl'd and installed I opened up Vivado and got eight critical warnings about entering negative values into the DQS clock delay could make the DDR fail. Upon loading up the block diagram I opened the Zynq customizing dialog and found these values in the DQS to clock delay fields:

DQS0: -0.050, DQS1: -0.044, DQS2: -0.035, DQS4: -0.100  , and in the board delay fields I found these values,

DQ[7:0]: 0.221, DQ[15:8] 0.222, DQ[23:16] 0.217, DQ[31: 24] 0.244

Then I opened my OOB project that doesn't work and looked at the same DQS clock delay values and found:

DQS0: 0.217, DQS1: 0.133, DQS2: 0.089, DQS3: 0.248 and the board delay values were

DQ[7:0]: 0.537, DQ[15:8] 0.442, DQ[23:16] 0.464, DQ[31: 24] 0.521

Then I opened my Hello World project that does work and found these values:

DQS0: 0.0, DQS1: 0.0, DQS2: 0.0, DQS4: 0.0  , and in the board delay fields I found these values,

DQ[7:0]: 0.25, DQ[15:8] 0.25, DQ[23:16] 0.25, DQ[31: 24] 0.25

I then installed these values into the OOB project and it worked...i.e. the SDK hit my breakpoints, variable values were shown and registers were getting filled, etc. and I could step through the code. Also any changes I made were shown.

The values for the Audio DMA project were in the …\board_files\zybo-z7-20\A.0\preset.xml file. They are also the values that show when I select Calculated in the dropdown.

I don't know where the other project's values came from. All the preset.xml files I searched and obtained had the same values as the Audio DMA project.

So having learned all about the above, I have these questions.

Since the DDR chip I have on my board is different than the B.2 schematic, and different than in the DDR config page, could I be provided the 'correct' values?

I did find the procedure on training DRAM in theZynq-7000-TRM.pdf, and the DRAM Training/Board Details are checked. So I could give that a try.

If you've gotten this far, thanks for your interest, and any help and guidance is greatly appreciated.

 

 

 

[ArKay99]

A follow up on this. I queried on this at Xilinx forums and got many hits relating to this as far back as 2016.1. After reading quite a few threads and responses, it appears that the negative values seem to be a default value that gets installed in the presets.xml file. A few remedies suggested were to leave them alone they will be ok, even though they may trigger warnings, to editing the values in the presets.xml to positive values. A Xilinx employee suggested to edit the file to have 0.001 in all the fields and make sure Write leveling, Read gate, and Read data eye are checked. There are other things that I did according to the preset.xml file and would be glad to share them if anyone is interested.

[BogdanVanca]

Hello @ArKay99,

From what I remember those values are calculated accordingly to the lengths of the pcb-routs. On earlier versions of Vivado leaving the unused fields blank, would not lead to any critical warning. In Vivado 2017.4, I also experienced those warnings, and my personal decision was to leave them alone. Normally it is impossible for those values to be negative but Vivado never ceases to amaze me. I would be extremely curious to find out what you i'v done more in this direction.

Best Regards,

Bogdan Vanca  

[ArKay99]

Hi BogdanVanca,

Thanks for the info as I assumed that what those values were for. I was looking for a 'sanity check' because warnings are warnings and I at least like to understand why. Also, the DDR on my board being intermittent and not knowing why was becoming frustrating to say the least. Here is what I did to arrive at my new set of values which seem to have fixed my issue. All this assumes that the preset.xml file is from a Zybo Z7 Rev B board. I have no way of determining the trace lengths without gerbers, and even then I don't have the tools to get a measurement that precise. I would assume those values would have to come from the pcb designer...

Since I had the manual for the Zentel chips at hand, under DDR Controller Configuration

I left Memory Type at DDR 3 (Low Voltage)

Memory Part set to Custom

No other changes here.

Under Memory Part Configuration:

Changed Speed Bin to DDR3 1600K

CAS Write Latency (cycles) to 6.000000

tRC to 48.75

tRAS to 35.0

tFAW to 40.0

Those were the 'small changes' I made.

I then set the DSQ0-DSQ3 values to 0.0 and the DQ[0] to DQ[3] at 0.25 and things started working again. However, I was puzzled as to how the values that were so far off got into the DQS and DQ fields. So I did a few searches and came upon this thread: https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Package-pin-delay-considerations-for-Zynq-PS-DDR3-PCB-routing/td-p/495444 . I thought I was on to something and then upon generating the pin delay values and the package die pin values, as referenced in that thread, I started calculating the values. When I did the averages of those values, to my surprise I got the exact same values as were in the preset.xml file. Afterwards I also found those values in the I/O Planning Layout spreadsheet. So, after reading through that thread and the other linked thread, and putting it all together, it looks like that warning is suspect. The calculator gives as the CLK0-CLKS3 lengths is 18.8mm and the lengths of the DQS0-DQS3 values vary from 22.9 to 29.7. When the clock path delay is subtracted from the Data Strobe delay if the clock path is shorter than the data strobe path, you will get negative numbers. This seems like an entirely possible scenario, and one that works when the negative values are used.

One last point and one that sort of answers my question of how those numbers got entered that stalled my DDR. Yesterday as I said, I entered the delay values into the appropriate fields based on the reports and averaged the delays to end up with the numbers in the preset.xml file. Then I closed the DDR configuration window and went about the other work on SDK side of things. This morning I opened up the DDR Configuration window to find the values had changed. When I opened up the calculated windows to reveal the delay calculator all the path delays were what I had entered, the same as preset.xml and the lengths I had entered were 0. When the values were then 'calculated', the resultant DQS to CLK Delay was different. I even had a positive vale for the DQS1 DQS to CLK Delay. I checked the preset.xml file and those values were untouched. So there is one possible reason for the delay values becoming 'out of bounds'...a bug?

So, all of the above has given me a bit of enlightenment on the workings of the DDR controller, it's parameters, the version of memory I have, and a lot of the surrounding factors.

[Sami Malik]

Hi ArKay99

You can't write to memory 0x0010000 of DDR in zybo. I don't know exactly what is the reason behind it but you can't read or write on it. You can use starting address something like 0x00200000 or something else, then you will surely not receive this error.