Memory Write Error Microblaze

[bklopp]

I get the error when I try to use the ddr OR when I try to use block ram. I have been stuck on this problem for a few days now. I recreated my project from scratch twice now. Any help will be greatly appreciated.

EDIT: Here is some additional info

Here are the address editor in vivado:

Here are the addresses in the SDK.

[xilinxacct]

@bklopp

Are you writing beyond the bounds of your memory? Did you set up the address for you memory?

[bklopp]

Yes I set up the linker script to be within the bounds of the ddr memory on my board. 0x800000 is the beginning of my ddr memory, so it's strange that I see this error even when I try to use block ram.

I will supply more details about the problem soon.

[bklopp]

The OP has been updated with additional information.

Edit:

It looks like that I can use Block Ram, so it must be some setting with the MIG.

Edit 2: No I can't use block ram. I have not been able to figure out what causes this. My co worker recreated the project in 2017.4 and this did not happen, so I'm installing 2017.4 to try to make one myself.

[bklopp]

Okay here's the additional details in a pdf attached to this post, as well as a tcl script of the design. If anyone could jump in and help that would be great. This happens on Vivado 2018.1 2018.2 and 2018.3. I have a working backup project that if I delete the mig and put it back in from the board file menu, I end up with the instruction insert overrun error (mentioned in my original post) after I generate the bitstream. This also happens when I create a fresh microblaze project.

And like I said, this happens if I try to use block ram OR DDR, so the other solutions on the forum did not help me.

@jg_bds

[jg_bds]

From your .TCL file:

#*****************************************************************************************
# NOTE: In order to use this script for source control purposes, please make sure that the
#       following files are added to the source control system:-
#
# 1. This project restoration tcl script (broken_project.tcl) that was generated.
#
# 2. The following source(s) files that were local or imported into the original project.
#    (Please see the '$orig_proj_dir' and '$origin_dir' variable setting below at the start of the script)
#
#    "C:/SVN/fresh/fresh.srcs/sources_1/bd/BD/hdl/BD_wrapper.v"
#    "c:/SVN/fresh/fresh.srcs/sources_1/bd/BD/ip/BD_mig_7series_0_0/board.prj"
#    "C:/SVN/fresh/fresh.srcs/constrs_1/imports/new/constrainties.xdc"
#
# 3. The following remote source files that were added to the original project:-
#
#    <none>
#
#*****************************************************************************************

Doesn't want to work without these files...

-Joe G.

[bklopp]

Here are the sources:

https://drive.google.com/open?id=1DAPG6JECqLUv-NMd8oC_0q3JIVuJK4ta

[jg_bds]

Sorry; still no joy:

     set_property -name "board_part" -value "www.qortek.com:directdrivebp:part0:1.1" -objects $obj

Gotta leave this for others now.  Work beckons.

Some shots in the dark:

• Your AXI data width should be 128, for 16-bit DDR.
• Have you tried moving the DDR address--to 0x2000_0000, maybe?
• Monitor MIG "init_calib_complete" output & make sure it's high.
• Verify MIG "sys_rst" is not asserted.

-Joe G.

[bklopp]

I set the ila to trigger when init_calib_complete rises, but that never happens when I launch the program. The axi bus to the mig remains inactive. sys_rst is low-active, and it remains asserted as it shoud be. 

[jg_bds]

I assume you mean "sys_rst is low-active, and it remains [high] as it should be".  A low-active sys_rst should not be asserted (i.e., low) during normal operation.

The DDR interface IP only needs a clock and a reset removal to come to life. What's the state of mmcm_locked? Perhaps something has happened to your sys_clk input.

-Joe G.

[bklopp]

locked is high. Does that mean there is no clock input to sys_clk_i? I'm about to investigate the clock signals once the build finishes. I attached the block design to this post as well.

[jg_bds]

The MMCM is locked, which means there's a suitable clock.

The reset is high, so the module is out of reset.

All should be good.

But initialization and calibration are not completing. 

Is this a known-good PCB, or is this a new custom-built board? 

If it's the former, then perhaps a DDR rail (VTT or VREF) has gone bad. If it's the latter, perhaps you should try running at a slower memory-clock rate.

-Joe G.

[jg_bds]

I just noticed the sys_clk for your MIG IP is coming from another, internal MMCM/PLL. That's bad. The sys_clk for a MIG should come from an external, low-jitter source. This might be causing problems, especially if you're trying to run the IP at its top speed.

Try tapping-off the sysclk that feeds clk_wiz_1, and use that clock as the reference for you MIG. Note that you can use the MIG to generate (up-to 5) additional clocks, apart from the ones required for the operation of the MIG. 

-Joe G.

[bklopp]

I should have mentioned in the OP that I have a working project that runs perfectly fine on this board with no memory error, so it's not a PCB issue. Any time I create a new project for this board or one of our other boards (same exact model), I get this error. At some point something either on my system or in vivado changed to make this error happen, but I'm not sure what did. I thought that maybe the board file or pins file got changed, but I compared those files the broken project is using with the ones used in the working project and they were identical. I'm baffled because I have been following the same step by step procedure to create a microblaze server for months, as outlined in this tutorial, with no problems whatsoever. It instructs you to use a 200MHz clock from the clocking wizard (Im not saying they're right, though).

I created the board files for our board by editing the nexys video board files and it worked. I could create new working projects up until about a month ago. The biggest change was that my company switched to a domain type setup where certain folders are no longer accessible. I doubt that has anything to do with the problem though because I can create a new microblaze server project for the nexys video just fine.

[jg_bds]

I just noticed you set the ILA trigger to "R" when checking init_calib_complete.  Set it to X and see if this line is high or low.  If a rising edge occured, it probably happened before you armed the ILA.

-Joe G.

[bklopp]

It's still low.

So I changed the mig addresses to 0x2000_0000, and that made the instruction insert overrun error go away when I launch the program, however, the hello world example I'm running does not print to the terminal and it does not breakpoint in the beginning of the program like it would if it was working.

[jg_bds]

Well, the un-asserted init_calib_complete is the first-priority problem that must be overcome.

If you implement the Example Design for the MIG you're generating and place it in your FPGA instead of your current design, does the init_calib_complete go high?

-Joe G.

[bklopp · Accepted solution]

This problem was caused by too long of a file path length in windows. My solution was to use a batch file to shorten the path to my project, then rebuild the project. The paths to the MIG get so long that vivado no longer sees those files when it does a build: 

SUBST /D T:
SUBST T: C:\<path to your project>
PAUSE

I then put this batch file in my startup folder in windows so that it would run every time and my project would always be accessible in the T: drive.