After updating to Quartus Prime Standard 20.1 compilation of the DDR3 SDRAM Controller IP fails. (Error log attached).
I also tried to solve the issue by installing WSL as described in following community case, but without success.
I'm Adzim. Thanks for using Intel Community.
I have reviewed you error logs and look like this is a known issue.
I have saw that you already tried to fix the issue by installing the WSL on your OS.
I believe that you already refer to this:
But the difference is that they have used the Ubuntu version 18.04 while you are using version 20.04.
I'm wondering is this can make a difference in solving your issue.
Would you able to use Ubuntu version 18.04 LST instead of 20.04?
After the installation has completed, can you launch the Nios2 Command Shell?
yes, at my first attempt I installed 18.04, with the same result.
20.04 was my last attempt, following the instruction of the las post of following community case.
Nevertheless I just uninstalled 20.04 and reinstalled 18.04 and successfully launched the Nios2 Command Shell.
Have you restart your computer after the installation process?
Do the error messages are prompting the same thing with your first one?
I have looked internally and found this from the engineer.
To debug this, ensure WSL is installed correctly on the Windows machine and you can test this by launching Nios2 Command Shell.
Next step, it would go to the IP owner to determine if they are invoking Nios2 Command Shell correctly.
In all scenarios, Qsys merely evaluates what's written in the IP's HWTCL file. If it fails when attempting to run something from the IP's HWTCL file, it is most likely something not working within that IP.
Can you identify it?
just gave it another try.
1. Restarted Computer
2. To see if everything is correct launched Nios2 Command shell (see attached screenshot)
3. Picked DDR3 SDRAM Controller with UniPHY Intel FPGA IP from the IP Catalog
4. To keep it simple: Selected Elpida EDJ1108BASE-8C from the Presets tab.
5. Finish and generated it without Example Design
It resulted in exactly the same Error log.
I've found some steps that have been used by the engineer.
Hopefully it's work with you.
Can you test it?
- uninstalled Ubuntu 18.04
- uninstalled wsl
- re-installed wsl
- downloaded latest Ubuntu 18.04 from Microsoft Shop & installed it
- executed following on Ubuntu shell :
sudo apt-get update
sudo apt install wsl
sudo apt install dos2unix
sudo apt install make
sudo apt-get upgrade
Let me is this can help you.
after reinstallation of the components in your suggested order, I am still not able to compile the DDR3 IP.
I also tried to uninstall everything (including Quartus) and install it in the order of WSL, Ubuntu, Quartus but still without success.
After that I did the same on another pc. On this computer the IP compilation was successful.
I really don't know whats the big difference between my working pc and the one, where compilation was successful. (Windows-Versions are almost the same)
Maybe I have to completely reinstall Windows to be successful on my working pc.
It's nice to hear that you can solve the issue.
But unfortunately, it's in other PC.
May I know the windows version on your other PC?
It's looks like the Quartus is not compatible in your current windows version.
I think you have to downgrade or upgrade your windows to match with your other PC.
Hopefully that can solve your problem.
yesterday I completely reinstalled Windows on my computer (it was time anyway), but even after that the IP doesn't compile on my computer.
So I removed wsl, Ubuntu and quartus on both computers, made sure that both have the same Windows build installed and simultanously did a step by step installation of wsl ubuntu and quartus. Result: Works on the other pc, but not on mine.
As a last try I installed Quartus Pro19.2. on my computer (as it is installed on the other pc from an evaluation in the past), but without success.
I really don't know, what now differs the two computers, letting pass the compilation on one and not on the other.
What is the windows build version in both of the pc?
I think you need to regenerate your project file if it's possible.
Can you try the workaround from this KDB:
Can I have the error logs after you reinstall the windows?
the windows build version is 19043.1165.
I tried the workaround although it doesn't make much sense to me. As expected, it reported, that Windows Subsystem for Linux is needed.
I assume this workaround is for Quartus versions <19.1 where cygwin is used instead of WSL.
Please find the error log after the reinstallation of windows attached.
Thanks for sharing the error log.
It does looked like still the same errors.
I guess you have to use the quartus in your other computer.
You already reinstalled everything in your main computer but still cannot solve the problem.
But your other computer can simply solve the error when applying the workaround.
Even both computers are same.
Or is there any difference between the computers?
But if you still want to use your main computer, maybe you can implement the quartus into the virtual machine(vm).
But I'm not guarantee it will work.
I hope that you understand about this.
technically the computers are not the same. Mine is much older and of course has different hardware. But I don't see how this could impact the compilation process of the DDR3 controller. And if you don't see anything in the error log, I truly understand, that you are running out of ideas.
I just wanted to evaluate the improvements made to qspi flash support, as I think that it is not ideally implemented in Quartus 18.0, the version I am working with at the moment.
Nevertheless, thank you very much for your support.
Yes that what I mean.
Your computers might have the differences but that differences shouldn't cause the error.
And your computers have the same build internally.
By right it should be work normally as other computer.
I'm sorry for cannot help you to solve this.
But maybe you can continue your project in your other computer.
I'm hope you are fine with that.
Thank you for your understanding.
I think I finally found the reason, why it worked on the other pc and not on mine.
One difference was, that the windows user account on the other pc was a local one, called Admin.
So I additionally added to my domain account on my working pc, a local one called "ChrisLokal",
After that, it also worked on this pc.
To verify my assumption I additionally created a local account called "Christian Lokal", resulting in the known issue during compilation of the DDR3 controller.
So, my assumption is, that the problem is related to the space in the user account name between "Christian" and "Lokal". (There is also a space in my company domain account.)
Hopefully this information helps to reproduce the problem and pinpoint you to the cause of the issue.