Nexys4-DDR Advanced I/O Demo ( Built-In Self-Test) throwing timing failed error using 2016.4 Vivado

[sumeet]

[dfergenson]

I'm appending this to this thread because it references the zip file posted in response to the initial question. Please feel free to recategorize it and to remove this header if you chose to move it.

I was able to successfully synthesize and implement the demo using Vivado 2016.4. Thanks for pushing out the update.

When I run it, I see a black rounded rectangle where the Vivado logo should be. I think that this is because I overwrote the logo in memory when writing the .BIN file, though I can't be sure.

I was unable to find a logo file to replace it which I'd like to do because I'm trying to work out how to implement an HMI of my own.

Can you please point me towards the original logo file? There's a comment within LogoDisplay.vhd that says that it is located in the bram_1.ngc file but I was unable to locate that file.

I see that a component called BRAM_1 is declared and it appears to use IP to reserve the memory space for that data. Am I correct to assume that the bram_1.ngc file should be loaded as the Init file under the Other Options tab in the IP configuration generator? The file extension that that options uses is .coe. Is there a .coe version of the logo then?

Or is my explanation of what has happened simply incorrect?

Any instructional resource that you could point me towards would be greatly appreciated.

-David

[dfergenson]

I've been continuing development and I'm using fairly large blocks of BRAM (40 of the 50 BRAM blocks available on the Basys3) and I'm still getting synthesis times of ~3 minutes. So there is something about the Nexys4DDR VHDL example code that specifically takes a long time to synthesize. I'm still curious as to what it might be but I've found a functional workaround in the form of the streamlined code that I'm synthesizing. If the problem rears its ugly head again, then perhaps by comparing the two offending projects with the successful one I'll be able to figure out what's going on. If I do so, I'll create a new thread since it's really a different problem. So anyone who is watching this one for the answer should follow my account instead or else send me a private message and I'll let you know if I do start that thread.

Thanks again for all of the help.

-David

[dfergenson]

Thanks, Jon. I'll run some controlled experiments with BRAMs of different sizes.

I don't think that the complexity of the code explains it. I've synthesized far more complex projects in the same ~3 minutes. Something tells me that this is a Synthesis 101 level issue but I may be underestimating it.

In any event, I'll post my results to the forum.

-David

[jpeyron]

Hi @dfergenson,

I got similar situation with synthesis done on 30 seconds for the basys 3 gpio demo with screen shot and project attached below. If you look at the logs selection at the bottom of vivado 2017.1 in each project you can see that the ported project you shared synthesis's a lot more items due to the project being much larger along with having the bram. I believe this is the major difference between the two projects and what is causing the time difference.

thank you,

Jon

Basys-3-GPIO-master.zip

[dfergenson]

Thanks, Jon.

Actually, could you compare it to the synthesis time of the Basys3 basic demo file which has similar VGA functionality?

The most obvious difference between the two is the population of the BRAM but I can't imagine that that would add 6-7x the synthesis time.

-David

[jpeyron]

Hi @dfergenson,

I do not have a mac so I'm not able to look at the _maxosx files but I was able to run synthesis in your GUI_LogoAndMouseLongSynthTime(also do not have spaces in your folder names or paths because it messes with vivado) project. It took a little over 15 minutes attached screen shot and your project with the synthesis run on my system. I'm running window 7 with a 4 core 3.40GHz I7. Tomorrow i will make the nexys 4 ddr version of this and see what i get.

cheers,

Jon

GUI_LogoAndMouseLongSynthTime.zip

[dfergenson]

Thanks.

I'm running on a 4 core 2.6 GHz Core I7. I have Windows7 running through Parallels simultaneously with MacOS X. It's running on an SSD.

So it's hard to say exactly how much processing power is being brought to bear against the synthesis but it's a medium amount.

The issue, as far as I'm concerned, isn't the total time that it takes but rather how much longer it takes. If its much faster to synthesize the Basys3 example with more features then there must be an issue with synthesizing the ported Nexys4 example.

[jpeyron]

Hi @dfergenson,

I will be looking further into you question tomorrow to see if I can get the duplicate it. Also How many cores are you using with Vivado 2017.1?  

cheers,

Jon

[dfergenson]

Thanks, jpeyron and whosaidturkey. I was able to implement the COE and see the logo.

The BMP to COE m file will be extraordinarily useful for the work that I'm doing. I can't wait to test it out.

I'm investigating an issue that may be related to the BRAM and definitely involves the Nexys4DDR demo so I'm including it here, though I can move it to a new thread if that would be helpful. It also involves the Basys3.

I synthesized and implemented the Nexys4DDR demo file that jpeyron provided and it took roughly 25 minutes from initiation to a generated bitstream. It took about 3:20 to synthesize the Basys3 demo and I'd initially chalked that up to there being more fabric on the Nexys4's Artix7 100T vs. the Artix7 35T on the Basys3. I now know that to be incorrect and I'm trying to find what's causing the hang up. I've managed to put the problem in a box.

Because I had misattributed the long synthesis time to the more capable FPGA and because I'm probably not going to use most of the 100T's fabric, I tried porting a simple mouse and monitor GUI from the Nexys4 project to the Basys3 in Vivado 2017.1 (which is worthwhile upgrade from 2016.X). It takes the same ~25 minutes to synthesize on my computer while the Basys3 GPIO demo takes the same 3:20 or so. I've posted my code to a project on GitHub: https://github.com/dfergenson/GUI_LogoAndMouseLongSynthTime

I looked on the Xilinx Vivado forums for typical reasons for slow syntheses and they mentioned two possibilities: clock domain conflicts requiring extraordinary syntheses to resolve and RAM being implemented in flip flops. I looked through both synthesis reports and the flip-flop issue does not seem to be a problem. My VHDL seems to keep the clock flows clean, too. I've attached both synthesis and utilization reports to this document.

So I haven't been able to resolve the issue. Have you observed the long synthesis time yourself? Do you have any thoughts as to what the bottleneck may be?

Thanks.

David

Basys3GPIO_demo_utilization_synth_Report.txt

Basys3GPIO_demoSynthesisReport.txt

PortedNexys4_utilization_synthReport.txt

PortedNexys4SynthesisReport.txt

[jpeyron]

@whosaidturkey,

Thank you for posting your 24-bit resolution bmp and coe files! 

cheers,

Jon

[whosaidturkey]

Thank you @jpeyron!

As mentioned before I found a bunch of scripts online to convert a picture to .COE file. These were useful but I ended up writing my own script to create the .COE because the Nexys 4 DDR uses 12-bit color. I attached my Matlab script for replacing the logo picture. It takes a 24-bit pre-cropped image (280px X 335px) and generates a .COE file that I got working yesterday. 

Let me know if anyone has any questions about this script. 

-Mark

byu-medallion1_24bits.coe

BMP_24toCOE.m

byu-medallion1_24bits.bmp

[jpeyron]

Hi @dfergenson and @whosaidturkey,

This project was just recently updated to Vivado 2016.4 and the missing logo(black box) was added and is here. 

cheers,

Jon

[whosaidturkey]

David,

I know I'm a newbie but I've been going through the same process. 

The coe files for this project are found in the project files:

\...\User_Demo\src\others

You're correct. In the Other options tab, of the BRAM Generator,  add this .coe file (or one like it). I've found several scripts online to create .coe but I'm still in the process of testing them. I'll update this post if I find something that works for me.

-Mark

Nexys4_all.bmp

Nexys4_all.coe

[jpeyron]

Hi whosaidturkey,

As it stands right now we will not be able to upgrade the Nexys 4 ddr User Demo to Vivado 2016.4. It will be maintained on Github with the Vivado 2015.2 version. This project is still on our list of projects/IP's to update/Fix. The expectation is to update it to Vivado 2016.4 when time permits us to dedicate the resources needed to do this. 

cheers,

Jon

[jpeyron]

Hi whosaidturkey,

So far the updates have not been fully completed. I will know more about this situation tomorrow afternoon. As of right now I am not sure if the updates will include fixing the issue with the accelorometer. I believe the updates will not include the timing issues which will not be a quick fix. I believe it will include setting up piping for the timing issues to be eliminated. 

cheers,

Jon

[whosaidturkey]

jpeyron,

You mentioned an update scheduled for Feb 15. Did this update happen? 

If so, does this include the fixes you mentioned in your last message. If so I might move back to an older version of Vivado.

thanks,

Mark

[jpeyron]

Hi whosaidturkey,

Thank you for pointing this out. I was able to get the accelerometer display to work correctly in Vivado 2015.2 (still had to update IP cores). I am thinking that it is an issue with the version. We are in the process up updating our projects to Vivado 2016.4 and i will point this out as an issue. Unfortunately, I would not be able to give you an ETA for this issue to be resolved.

cheers,

Jon

[whosaidturkey]

I am seeing the same warning as Sumeet in 2016.2. 

Another problem with this demo (maybe I should put this in it's own thread, idk)

I'd appreciate help on is with the accelerometer Display. After synthesizing my own bit file and making no changes to the HDL, the VGA display of the accelerometer display with the green square seems to have a problem with acceleration that is less than 0. It works fine for board rotation in positive directions but when I rotate the board the other way the red square jumps to the left. The x value seems to be problem. Has anyone seen this before?

Possible reasons I can think of - I updated the IP Cores for this project. Possibly the logicore Square Root core is causing this problem. Does anyone know if using version 6.0 (rev 10) with this demo project is a problem?

[jpeyron]

Hi sumeet,

I know that we are upgrading our IP's to 2016.4 with an ETA of  Febuary 15th. We will be looking the timing issue during this process. I have tried the project in 2015.4 and 2016.4 and in both projects there are the timing issues. I was still able to generate a bitstream and run the project. Are you able to generate a bitstream and run the project?

cheers,

Jon

[sumeet]

Hello,

I tried executing the project and found that the design is still showing critical warning related with timing. In fact I had already ported the design for 2016.4 version. My actual issue was timing failed status which is still showing when I used your uploaded design. Now, my question is how to get rid off the timing failed!! warning obtained after the implementation step. I am able to see the visual outputs but struggling to get rid of the set up and hold time violations.

[sumeet]

Thank you so much for the quick upload..

[jpeyron]

Hi sumeet,

I have attached a zipped project of the user demo in Vivado 2016.4. We are in the process of updating our Nexys 4 ddr Github projects to Vivado 2016.4 with an eta of 2/15/17.

cheers,

 Jon

User_Demo.zip

[jpeyron]

Hi sumeet,

I just generated bitstream for the User_demo in vivado 2015.4. Tomorrow i will get it working in Vivado 2016.4 and update our github. I will let you know on this thread when it is ready for you to get it off of our github.

cheers,

Jon

[JColvin]

Hello,

I have moved your question to our FPGA section of the Forum, so that way one of the Digilent engineers familiar with that particular demo of ours will be able to see and respond to your post.

Thanks,
JColvin