Issue with MIG for Arty S7-50 on Vivado 2017.2

[Abdoulaye BERTHE]

Hi,

I am experiencing an issue with the mig 7 series interface for Arty S7-50 on Vivado 2017.2. I downloaded the board files from the https://github.com/Digilent/vivado-boards/archive/master.zip and copied them in C:\Xilinx\Vivado\2017.2\data\boards\board_files\.

Adding the DDR3 SDRAM from the board tab or a MIG interface using add IP and trying to customize it always result in the error below. 

Has anyone experienced this?

Thanks.

 

[jpeyron]

Hi @Abdoulaye BERTHE,

I have been able to duplicate this issue. Unfortunately I have not been able to resolve it yet. While we are researching this issue I have two working microblaze projects. Here is a forum thread that has links to two different completed GitHub projects that use Microblaze without an issue. One of the GitHub projects use the ddr3 sdram as well.

thank you,

Jon

[Abdoulaye BERTHE]

Hi Jon,

any progress on this?

In the project link it is said that it was created with Vivado 2017.2 which is the version that I am using. How did you manage to do it?

https://github.com/Digilent/Arty-S7-50-base-rt

[jpeyron]

Hi @Abdoulaye BERTHE,

Unfortunately, I have not made any progress. I am also having the same issue using Vivado 2017.3. I have reached out to the engineer that made the linked project for more insight. They have been out of the office the last few days. I am hoping to be able to give you a response next week.

sorry for the inconvenience,

Jon

[sbobrowicz]

@jpeyron @Abdoulaye BERTHE

I am unable to replicate this in Windows 7 or Ubuntu 16.04. What is your operating system? Can you also provide your system specs (RAM, CPU, etc.)?

Also, are you able to click "run block automation", or does that cause the same error? Does it only occur when you double click the MIG IP core?

One thing that is different in my setup vs. yours, is that I install the board files by creating a file called init.tcl and placing it in C:\Users\<WindowsUserName>\AppData\Roaming\Xilinx\Vivado

The file just needs the following line (and should also have some newlines at the end to be safe):

set_param board.repoPaths [list "C:/sam_work/git/digilent/vivado-boards/new/board_files"]

You should replace the path with a path to where you have downloaded our vivado-boards package. This is the safer way to install our board files, and is convenient because you don't need to install them again every time you install a new version of Vivado. We still need to update our documentation to use this new method. Bonus convenience points if you use git to download the vivado-boards package, because then it only takes a simple "git pull" to get the most recent changes, and we are constantly making fixes/improvements.

[Abdoulaye BERTHE]

@jpeyron @sbobrowicz

I tried the method above, it does not work. Please find my system information below, I am using Vivado 2017.2. I purchased the Arty Z50 board a few weeks ago because it is said to be supported in Vivado. I am thinking about posting my experience with the MIG in the review section of the Z50.

 

[jpeyron]

Hi @Abdoulaye BERTHE,

I am in the process of making a ticket for this issue with Xilinx. I am very sorry for the frustration this has caused. 

thank you,

Jon

[jpeyron]

Hello @Abdoulaye BERTHE,

I am working with Xilinx on this issue through their support channels about the Arty-S7-50 and the issue with the MIG. I am hoping to hear more about this issue early next week.

thank you,

Jon

[jpeyron]

Hi @Abdoulaye BERTHE,

The Xilinx support was able to duplicate this issue. After some research Friday and over the weekend they found that it is a problem with Xilinx's WebPack install and Spartan-7 Devices.  They have filed an internal CR to resolve this issue. On a side note, they were able to resolve the runtime error by upgrading the install to Design Edition.

thank you,

Jon

[jpeyron]

Hi @Abdoulaye BERTHE,

I confirmed that upgrading to the Design edition resolved the runtime issue with the MIG. A screen shot of this is attached below. You can upgrade Vivado to the design Edition and use the Design edition without needing the design license as long as you are not targeting a device that required the design license for use.

cheers,

Jon

[sausemichel]

Hey folks,

I am also working with the Arty S7-50 Board (and most time i like it ). But since two weeks I am trying to interface DDR3 without any success. So far, I could not found any template or tutorial about how to implement a DDR3 Interface without Microblaze. MIG is working now (thanks to this Thread) but its entries differ to the ones assumed in the Arty S7 Reference Manual...

Has one of you managed to get the interface running already? Every hint or example could be usefull for me.

Thanks!

Michael

[D@n]

@sausemichel,

There is an Open Source Arty A7 project that uses a ZipCPU without microblaze.  It both describes in the spec how to set up the MIG controller, as well as offering Verilog examples of how I did it--should that be of interest to you.  I also made heavy use of the board file (it's legible XML) to get there--should you run into trouble along the way.

Dan

[sausemichel]

@D@n

Thank you for your answer! Its a nice project you have developed. May be, I could use some Parts of it. 

Unfortunately I would like to use the native interface, without AXI. Putting the Interface into operation fails because of clocking issues. If you use a block design, you can generate additional clock signals for driving the reference clock. But using MIG from the IP Catalog does not give you this option,  especially because Vivado does not allow you to change the hdl files. I think, I'll annoy the xilinx support with that .

I wish you a merry christmas!

Michael

[D@n]

@sausemichel,

I look forward to trying out the native interface myself, I just ... haven't gotten around to it yet.

I was personally disappointed, working on that project as I have, that the AXI interface for the MIG component had a *very* restricted set of frequencies that it would work with.  Part of the issue was the complexity of the MIG controller.  Another part of the issue was the part.  The third part was the DDR3 spec itself.  Between these three, I found my choice of system clock frequency to be *quite* limited.  Yes, I could've crossed clock domains ... but I was trying to be "fast" and that tends to add additional latency to the memory access.

Dan