01-03-2019 02:06 PM - edited 01-04-2019 06:13 AM
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.
01-14-2020 01:32 PM
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.
01-03-2019 02:34 PM
Are you writing beyond the bounds of your memory? Did you set up the address for you memory?
01-03-2019 06:01 PM - edited 01-04-2019 05:38 AM
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.
01-04-2019 07:20 AM - edited 01-18-2019 11:52 AM
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.
01-18-2019 12:41 PM - edited 01-18-2019 01:08 PM
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.
01-18-2019 03:06 PM
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.
01-21-2019 06:44 AM
Here are the sources:
https://drive.google.com/open?id=1DAPG6JECqLUv-NMd8oC_0q3JIVuJK4ta
01-21-2019 08:15 AM
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:
-Joe G.
01-23-2019 11:36 AM
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.
01-23-2019 06:49 PM
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.
01-24-2019 08:16 AM
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.
01-24-2019 08:32 AM
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.
01-24-2019 08:44 AM
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.
01-24-2019 11:24 AM - edited 01-24-2019 11:25 AM
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.
01-24-2019 12:26 PM
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.
01-25-2019 07:09 AM - edited 01-25-2019 07:09 AM
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.
01-25-2019 09:56 AM
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.
01-14-2020 01:32 PM
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.