I am trying to run a .tcl file originally configured for 2014.4 on 2016.4 version of Vivado. However I am getting the following error:
while executing
"create_bd_cell -type ip -vlnv xilinx.com:ip:mig mig_0 "
(procedure "create_root_design" line 111)
invoked from within
"create_root_design """
(file "all.tcl" line 405)
The tcl file uses the part 'xcku040-ffva1156-2' and tries to access the IP 'mig' which I believe is renamed/changed on later versions. Is there any workaround for this?
Steps I have done till now:
Changed the version number to 2016.4
tried replacing target boards.
tried on the same board with an alternate IP for mig.
tried on both 2016.4 and 2015.4 versions
None of these have worked so far
Attaching the '.tcl' file for reference : all.tcl
Since with every version upgrade of the Vivado Design Suite, parts are renamed or removed, it is not possible to run a .tcl file meant for an earlier version in newer releases. So I ran the above query on Xilinx Community Forums and found a workaround:
Run this script on the previous version(2014 in this case), generate the design and then open the same design using the next major release(2015 version). The 2015 version will automatically suggest upgrades to the discontinued/renamed IPs. Repeat the same to get to 2016 version. That's the only way to get this done. Also have to keep checking if the core functionality of the IP is the same after automated upgrades by Vivado Design Suite.
Related
Has anyone got dxgettext running under Windows 10?
I installed dxgettext from the offical homepage under Windows 10, which worked fine.
But whenever I try to run some of the installed tools (e.g. msgfmt.exe), they don't really run, but call themselves again, generating thousands of processes and making the system crawl.
This is what happens:
I call msgfmt --help
the executable msgfmt hangs, blocking the command window
in the TaskManager I see houndreds of msgfmt.exe processes popping up
I think, I have to replace the gettext tools of the dxgettext package with some newer version but before trying to figure it out I first wanted to ask if someone else experienced similar problems and found a working solution.
My questions:
Has anyone got the tools coming with dxgettext running under Windows 10?
What steps have been necessary to get it to run?
I resolved the problem in the following way:
I downloaded https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.19.8.1-v1.14/gettext0.19.8.1-iconv1.14-static-32.zip from https://mlocati.github.io/articles/gettext-iconv-windows.html
I replaced the following files from the installation directory of dxgettext with files from the zip archive:
msgattrib.exe
msgcat.exe
msgcmp.exe
msgcomm.exe
msgconv.exe
msgen.exe
msgexec.exe
msgfilter.exe
msgfmt.exe
msggrep.exe
msginit.exe
msgmerge.exe
msgunfmt.exe
msguniq.exe
xgettext.exe
Result:
Dxgettext and the tools, I use, seem to work fine. I found no problems with my workflow so far, with one exception:
If I use assemble to embed mo-files into an exe compiled with JvGnugettext.pas, I get the following error:
Pach code “6637DB2E-62E1-4A60-AC19-C23867046A89” was not found in .exe file. Are you sure the .exe file has been compiled with the correct libraries?
This may not be related to the original problem. However, it is resolved by replacing the original assemble.exe with the version from https://sourceforge.net/p/dzlib/code/HEAD/tree/buildtools/trunk/ (see answer by #dummzeuch).
The installer on the official home page is pretty old. Last time I looked it contained several outdated dlls and executables from the original gnugettext project that did not work correctly under recent Windows versions. You could take those from my buildtools repository on OSDN. These work for me. No guarantee that they work for you though.
https://osdn.net/projects/dzlib-tools/scm/svn/tree/head/buildtools/trunk/
I've been having these issues too with dxgettext 1.22, in Windows 10 1607. I changed some DLLs at first but kept having the bash.exe looping and hogging my PC to death.
So what I did was basically install latest Cygwin 32bit and replaced the appropiate DLLs. I kept the ones for gettext. Instructions:
Download and fresh install dxgettext-1.2.2.exe from http://dxgettext.po.dk/download as admin. Restart.
Download Cygwin 32bit from https://cygwin.com/install.html in a different folder from dxgettext (I took the default, c:\cygwin)
Run setup-x86.exe and select "Base" Package (Install). Next, Select Required packages just in case.
Move the following files from dxgettext folder to a backup folder (we'll use some DLL later):
cyg*.dll
bash.exe
Copy from c:\cygwin to the dxgettext folder the following files:
bash.exe (set to run as admin)
cygwin1.dll
cygiconv-2.dll
cygintl-8.dll
cygreadline7.dll
cyggcc_s-1.dll
cygncursesw-10.dll
Recover the file(s) below from the backup folder (See #4) and copy to the dxgettext folder.
cyggettextsrc-0-14-1.dll
cyggettextlib-0-14-1.dll
cygintl-3.dll
Running like this, you might get error 740 (requires elevation). So: Set ggmerge.exe,ggfmt.exe to run as admin
** EDIT** Found online this very interesting link, from a programmer who offers a free backup written in Delphi. The good thing is he adapted the dxgettext tools to run in Windows 10. This helped me a lot.
http://personal-backup.rathlev-home.de/translate.html
I'm trying to run pub deploy command in my Dart project, but it always ends with this error: "Pub deploy failed, [1] Cannot read link". No more information outputs into console.
I tried to run it in basic Dart browser project (the one with text reversing), but same error occurred again.
Did anyone have same problem? Any ideas how to fix it?
I have the same issue.
In my case, the Dart project is stored in NTFS hard drive (I share it with Windows OS) and Dart deploy (run from Eclipse) runs on Ubuntu.
Simply move the Dart project to Ubuntu hard drive then things come back to normal.
GS
This is probably a problem with the packages symlinks. If you delete them and run pub install it should work again.
According to dart-sdk/lib/io/link.dart:
On the Windows platform, the link will be created as a Junction
On other platforms, the posix symlink() call is used to make a symbolic link
On Linux platforms, storing Dart project in NTFS drive causes Pub to fail. Because posix symlink() is used on NTFS partition and doesn't create a valid NTFS junction point.
The solution is to move the project folder to a partition that uses posix symlinks natively, such as one formatted to ext4.
I'm trying configure PyScripter 2.5.3 to use a version of Python that is installed in a non-standard install location (i.e., c:\MyProj\Python27).
NOTE: I also have ActivePython 26 and 27 also installed, in the default locations c:\python26 and c:\python27)
I have a short program that simply dumps the python path to verify that I have the correct version:
import sys; print( "\n".join(sys.path) )
When I'm using the "desired version", I'll see "c:\MyProj\Python27\lib" show up on the path.
I've looked at several postings (one is How to change the version of python that pyscripter uses) and most just say the defaults work and the defaults do work. I'm trying to use a non-default directory.
I've used Tools | Configure Tools to set the Python Interpreter, and Command Prompt to run "MyProj" version of python.
So Tools | Python Interpreter, starts c:\MyProj\Python27\python.exe
Also Tools | Command Prompt, starts c:\MyProj\Python27\python.exe version.
But I can't get the Python IDE to use the desired version when I use "Run | Debug (F9)".
I've configured Tools | Options | IDE Options | Python engine type = peRemote.
I've also tried internal.
I've tried starting PyScripter from the command line with the following options (none of these examples worked)
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27\python27.dll
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27\python27.dll
I've tried having only my version of python on the windows PATH (removing c:\Python27)
set PATH=C:\MyProj\Python27;%PATH%
...\PyScripter.exe
This has also failed to work.
Has anyone had success at using a non-standard location? If so what steps were followed?
I don't know if this is the best way to do it, but those are the two ways I did it:
WAY 1 (The best of two)
Go to PyScripter>>Tools>>Options...>>Custom Parameters... and add the following values
1. PythonDir = C:\Program Files\CustomPythonInstallation
2. PythonExe = C:\Program Files\CustomPythonInstallation\python.exe
3. PythonVer = 3.3.3
Note: Adapt the Name = Value pairs above to your case.
And close the window with OK button.
Now select PyScripter>>Run>>Python Engine>>Remote and your are ready to go.
WAY 2 (The more temporary solution)
Go to PyScripter>>Run>>Configure External Run...
set the "Application:" field to your python.exe file
Close the window with OK button.
Make sure you run your scripts with PyScripter>>Run>>External Run (Alt+F9)
I hope this helped, good luck.
I'm using two different pythons, tried to use pyscripter with both, but it kept messing up. My simple solution was to download the standalone pyscripter that doesn't use the registry, put copies into two different directories, then set each up for the different py. You can then right click on their icons and set them to start in the proper directories. You can also make two cmd icons and set them respectively so you have a command line. The command line icon can also be set to start in your working directory, although that's normally one level below python, and if it isn't on the path, you have to type ../python to get it (or use a keyboard macro for that.) This works trouble free.
I did delete both pythons and removed them from the system path just in case pyscripter looked for them. Then I installed 2.7 and set up the first scripter. I installed 34 and set up the second. Oddly, the scripters found the correct py each time - I imagine they go for the highest one. But you can also set that in scripter options. And frankly, it may not be necessary to delete py**. If not deleting them doesn't work you can just make a fresh copy of scripter and try again, since that will be a new standalone. For all I know you can reinstall python on the path once pyscripter is set up for each. I haven't tried that. Fiddle around. You can always make a new copy of the pyscripter standalone directory if things don't work out ;')
The interactions between the registry, the path, and the installed pyscripter just led to too many headaches.
Oh, pyscripter doesn't seem to play well with 3.4 but there's a fixed exe for your 3.4 standalone, here - just replace the 3.4 standalone python.exe with this one:
https://pyscripter.googlecode.com/issues/attachment?aid=7680027000&name=PyScripter-Updated.7z&token=ABZ6GAd40xS88r5vwgY9m8Y18vSFKN8q3g%3A1421517339924
I keep getting the same type of error messages and I have really done all I can to get rid of them. The message is as follows, only the module can vary at times:
ruby 5740 child_info_fork::abort: address space needed by 'date_core.so' (0x600000) is already occupied
These messages occur at various times when trying to run Rails, such as “rails console”.
I am running the following environment:
Windows 7 Ultimate 64-bit
Cygwin Net using setup 2.774 (installed from Internet mirrors)
Ruby 1.9.3p392
Rails 3.2.11
I have taken the following steps attempting to fix this:
Deleted all BLODA and restarted, including Norton 360 and Malwarebytes. (BLODA is Big List of Dodgy Apps.)
Deleted and reinstalled Cygwin.
Executed “rvm implode” and rebuilt the RVM and Ruby on Rails environment.
Used CMD & ASH to run “peflagsall” & “rebaseall”. Ran “rubyrebase”. Restarted.
Used FIND to build a file of all *.so & *.dll files. Ran “rebase -T”. Restarted. This has also been done using the “-b 0x77000000” switch.
Used same file to create “to_peflags” script issuing peflags against each individual file. Restarted.
All repair attempts have been futile. At times, “rebase -si |grep ‘*’” would be clean. Any attempt to run “rails console” or similar commands results in Address Space Occupied messages. Subsequent “rebase -si” would then again show conflicts.
I have been trying to run “peflags” against the Ruby modules, but I only get “skipped because could not open” error messages there. File permissions and ACL both show correct permissions. The same error occurs whether or not Administrator is used.
This is pretty frustrating. I would like to fix my current environment, but I am considering moving to MSYS or SFU, but I don’t know if either of those are decent options. I am also considering going native UNIX, but I’ll leap off the cliff when I get to it.
For now, does anyone have a fix for this specific error for me? Thanks…
I have used procexp to monitor "rails console" execution. Bash is calling cmd.exe to run the rails.bat file. Cmd.exe runs in ASLR mode. Used Microsoft EMET 3.0 to turn off mandatory ASLR and bottom up ASLR for both bash and cmd. Cmd.exe still runs in ASLR mode. It must be compiled that way.
Updated registry to set HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages to 0, -1 then 1. 0 caused system problems. -1 had no effect. 1, which was supposed to be the default, helped somewhat as long as EMET changes were in place. But, it was unreliable as Address Space Occupied would eventually recur.
Decided to attempt to install a command processor that either didn’t require ASLR or allowed me to disable it using PE flags. I installed TCC/LE and attempted to get Cygwin Bash to use it to process .bat files. I tried using the path variable, the COMSPEC variable and changes to batfile and cmdfile in the registry all to no effect. Cygwin Bash must either have it hard coded or some nonobvious control.
My fix is to replace my environment. I know I will eventually migrate to some Unix, but for now I am converting to MinGW/MSYS and RubyStack. All I want to do is to get a stable RoR (Ruby on Rails) environment running for today. I don’t see that happening using Cygwin with Windows 7 Ultimate. I keep running into too many problems and this one is a very, very tough nut to crack. Thanks…
I recently installed SpringSource Tool Suite. And I want to start working with Grails projects. So, I went to the Dashboard -> Extension, where I saw two extensions: Grails (current production release) and Grails Support as in the image below.
But when I try to install them, I get the following errors :
Problems occurred while performing installation: Operation details
Operation details
Cannot complete the install because one or more required items could not be found.
Software currently installed: Shared profile 1.0.0.1340820181092 (SharedProfile_com.springsource.sts.ide 1.0.0.1340820181092)
Missing requirement: Shared profile 1.0.0.1340820181092 (SharedProfile_com.springsource.sts.ide 1.0.0.1340820181092) requires 'org.maven.ide.eclipse [1.0.100.20110804-1717]' but it could not be found
What can I do to resolve this error ? Or are there any other options I can follow to install Grails extension?
Thank you!
I would switch to the new "Groovy/Grails Tool Suite" that was recently announced (see http://www.springsource.org/node/3582). Go to the standard download page at http://www.springsource.org/downloads/sts and click "Other Downloads >". Download the version for your OS under "Milestone Version - Groovy/Grails Tool Suite 3.0.0.M2".
It is a beta/milestone release but I've been using it since it was released and it's as stable as a final release so far. It's convenient since the Groovy-Eclipse plugin and the Grails support are already configured for you, in addition to the latest Grails (2.0.4). Any other plugins that you need from the standard STS can always be installed using the standard install/update procedure.
Yes, what #BurtBeckwith said. You should move to the new GGTS.
However, to address your particular problem, you installed STS into a read-only directory (or in C:\Program files). You need to re-install it somewhere else.
The Eclipse p2 installer cannot handle installing feature patches into a read-only directory. Groovy-Eclipse ships with a feature patch to extend the JDT compiler. I believe that this problem was fixed in the Juno release of Eclipse (4.2), which came out last week.
Deleting corresponding application from Windows memory removed the problem (Grails extension in SpringSource Tool Suite errors). Double running applications (earlier and new) could also be reason why GGS or STS sometimes cannot save .groovy files (with error message or without).