Before describing how to do all of this, I should put forth the following disclaimer. This information is provided as an aid for using the Xilinx tools under Linux. We are not "supporting" this information, though, if you have questions, we would be glad to help as time allows. Xilinx would probably laugh if you contacted them for support of this arrangement. Further, as always, you should stay within your number of contracted Xilinx licenses to remain legal and supported. This information should be in no way used to circumvent or ignore the license agreements for Xilinx software.
Another option, of course, would be to run VMWare or Win4Lin instead of Wine under Linux. The tools should run faithfully under Linux in either of those scenarios, but these approaches, of course, costs more (Wine is free while VMWare and Win4Lin aren't) and I would expect VMWare and Win4Lin to require more resources and overhead than running Wine, meaning the command-line tools might run faster under Wine.
The installation for these tools was very simple under RedHat 6.2. I simply:
Just so you know, I tried compiling Wine-20010629 under a somewhat-updated RedHat 6.2 installation of Linux, but there were some problems which could not be resolved quickly. I was getting Signal 11 problems during the compile of wine-20010629/dlls/shlwapi/ordinal.c on 3 or more different machines; as such, I don't believe it is a hardware-related issue. I suppose egcs-1.1.2-30 from RedHat is having problems. The new version of Wine might be interesting to try, if you can get it to build.
For Wine-20010510, the Xilinx Alliance 3.1i installation program also worked fine. The big news is that the Service Pack installers also work as well as the Device Update installer for Virtex 2. Further, the GUI for the installers looked close to perfect. The only extra work that I had to for installation was to add a few Windows DLLs to the "windows\system" directory for Wine. I tried two different sets of DLLs:
One issue you will probably run into is that you will need to mount the Xilinx CD-ROMs using the "-o norock" option. Apparently, the Rock Ridge extensions to ISO9660 used to create the software distribution CDs for the Xilinx tools are kind of broken. By using the "-o norock" option, the embedded Rock Ridge extensions are ignored and all should work fine. By the way, if you are wondering what to do to invoke the various installers, you simply change directories to the mounted CD-ROM data and execute the installer using Wine. For instance, you would do the following for the Device Update installation:
mount -o norock -o ro /dev/cdrom /mnt/cdrom
cd /mnt/cdrom
wine setup.exe
During the installation, I would not recommend having the installation program for the Alliance 3.1i tools try to modify the "Xilinx" or "PATH" environment variables for you. This has already been taken care of by the process described in Setting Up Your Environment: Alliance 3.1i/3.3i. I am not sure what this would even do---probably nothing useful. For that matter, I suspect trying to view the release notes after installation will also fail, so it probably isn't worth trying.
Additionally, with this newer version of Wine, you can now define global registry settings for the installation---this way it is easier to maintain the settings centrally. Therefore, after I installed the Xilinx tools under Wine, I copied the ~/.wine/system.reg file created during the installation process to /mirrors/usr/wine-20010510/etc/wine.systemreg---note that this file's name is not "wine.system.reg". I noticed that after I executed Wine as a new user, this file appeared to be copied to my local ~/.wine directory as system.reg. Apparently, with this new system, the user doesn't have to worry about registry maintenance quite as much since it can be centrally administered. I would suggest looking at the Wine User Guide to learn more about this.
Also, after the installation process, I suggest making the ~/.wine/user.reg created during the installation process available to the users of your installation. For instance, I have provided the ~/.wine/user.reg file created during the Xilinx installation process to our users via the Web (see the next section).
I should reiterate that, for the sake of this discussion, I will assume that Wine has been installed in /mirrors/usr/wine-20010510 and the files which have been mapped as the Windows "C" drive are located in /mirrors/usr/wine-c-20010510. Of course, for people outside of our lab, these two installation directories may be called something completely different, so please replace these paths as appropriate to your local installation.
With this said, I recommend the following for your Wine setup:
XILINX="C:\Xilinx";export XILINX
setenv XILINX "C:\Xilinx"
Executing a Program
I have created wrapper scripts for the most
commonly used Xilinx Alliance tools. A tar file of these wrapper
scripts, xilinx-wrappers.tar, is
available, if you would like to modify them. To provide some insight
into what these wrapper scripts do, let's assume that we are not using
the wrapper scripts for the moment and want to explicitly call the
Xilinx programs using Wine.
To execute a program such as ngdbuild without the wrapper
scripts, you can execute it using the following command:
wine ngdbuild
If you need to execute a Windows program with arguments (as we often
need to do), you should provide the arguments after a -- to
indicate to Wine that the arguments belong to the Windows program and
not Wine itself. For instance, you can execute fpga_editor
on pe1_Counters.par.ncd as follows:
wine fpga_editor -- pe1_Counters.par.ncd
A wine option you might like for some of the GUI programs
is the -managed option; this allows the window to be managed
by your window manager rather than the Wine environment. For example:
wine -managed fpga_editor -- pe1_Counters.par.ncd
The ~/.wine/config file referred to above makes "managed" the default mode for
windows created by Wine.In executing programs, you might have to deal with the mixing of UNIX and Windows-style paths. Wine itself doesn't mind commands like
wine /mirrors/usr/wine-c-20010510/Xilinx/bin/nt/ngdbuild
since it can do the translation to Windows paths, assuming, of course,
the subdirectory is mapped to a Windows drive in the
~/.wine/config file. To be safe, I use strictly
Windows-style paths for environment variables used by Windows programs
as well as for options passed to the Windows programs.If you use the wrapper scripts to execute the Xilinx tools, you can simply do the following:
fpga_editor pe1_Counters.par.ncd
or
bitgen -w -g StartupClk:Cclk -g readback -g persist:X8 -l -m -g DONE_cycle:6 X0.par.ncd
Caveats and Work-arounds
To begin with I should mention that, in the past, we have come across
some designs that did not complete under our old Wine setups
(Wine-991212 with Alliance 2.1i and Wine-20000821 with Alliance
3.1i). Thankfully, Wine continues to mature and we have noticed that
several designs which didn't complete under Wine/Linux in the past
complete just fine now. I believe that part of the problems in the
past had to do with the fact that we could not easily keep up with the
Xilinx service packs since they did not install directly under Wine.
Now that the service packs install under Wine and Wine itself has
matured some, I expect that we will see even better results. In the
past, about 97% or more of the designs were successfully processed
through the Xilinx Alliance tools under Linux. Considering that we
use the tools a lot, the Wine/Linux environment has been quite
productive for us. To this point, we have not encountered any designs
that won't process with our new Wine setup (Wine-20010510) for the
Xilinx tools, but we might encounter a few---you never know.
When executing programs with Wine, you may receive errors and messages like the following:
err:win32:DeleteCriticalSection Deleting owned critical section (0x40ec0ab4) err:win32:DeleteCriticalSection Deleting owned critical section (0x40ec0a54) err:win32:DeleteCriticalSection Deleting owned critical section (0x40ec09f4) err:win32:DeleteCriticalSection Deleting owned critical section (0x40ec0994) err:win32:DeleteCriticalSection Deleting owned critical section (0x78040e88)or
fixme:console:SetConsoleCtrlHandler (0x7800dd30,1) - no error checking or testing yetThese are common and to be expected. They are just messages from Wine relating debugging information and partially implemented emulation code. The 20010510 version of Wine has considerably fewer of these messages.
In the past, one of the biggest shortcomings of Wine as far as executing the Xilinx tools was concerned was that Wine didn't spawn other Windows programs properly; we had to deal with this when using Wine-991212. This had to do with the fact that Wine couldn't properly spawn other Windows programs when the programs had been stripped of their symbols. I am glad to say that since about May 2000, this support has improved and most Windows programs are able to successfully execute other Windows programs whether or not the symbols have been stripped from the binaries. For example, you can actually run the Xilinx Alliance 3.1i installer and Service Packs under Wine now. This is fairly amazing since the installers for the tools and Service Packs both spawn multiple Java processes to install and unpack things.
Unfortunately, I have noticed that ngdbuild can spawn its helper programs, but, for some reason, ngdbuild doesn't appear to know that the spawning worked. If you run ngdbuild several times it will eventually complete, depending on the number netlists which must be converted to the .ngd format from XNF, EDIF, etc. For now I would recommend the execution of the ngdbuild helper programs (xnf2ngd, edif2ngd, etc.) still be explicit in Makefiles and scripts.
As an example, with the Wildforce environment, there are a few XNF drop-ins. In this case, ngdbuild tries to spawn xnf2ngd to translate those files. Since I use Makefiles to process my design files, I just execute xnf2ngd, edif2ngd, and the other translators before calling ngdbuild. Note that your main design file must be translated as well as drop-ins before executing ngdbuild.
Unlike with Wine-991212, map under Wine-20000821 and Wine-20010510 is able to spawn m1map for XC4000 designs properly. As a little background, I have noticed that map actually spawns m1map for XC4000 designs, while it doesn't for Virtex. With previous versions of Wine, due to the process spawning limitations mentioned above, I replaced references to map in my UNIX/Linux Makefiles with m1map as a workaround for XC4000 designs. For Virtex designs, map worked just fine under Wine. With the later versions of Wine, you can just use map for both XC4000 and Virtex designs without any problem since the process spawning capabilities have greatly improved. If you start having problems with process spawning and map for XC4000 designs, you might consider using m1map again instead.
One small problem that I discovered with bitgen is that it writes out file names which only have lower case letters, even if the original design's file name had some capital letters. Of course, in Windows, this is not a problem since the tools tend to be case insensitive when it comes to file names. Under Linux, though, this complicates Makefiles and scripts, but it can be handled fairly easily if you know of the problem beforehand.
I'm happy to report that the problems with fpga_editor and the "open file" dialog boxes appears to have been solved under Wine-20000821 and later versions. In previous versions of Wine (version 991212, specifically), the file of interest would appear to be appropriately entered in the dialog box once selected, but it couldn't actually be viewed unless it was in the root directory for the emulated Windows drive. With these previous versions of Wine, if you would really wanted to view a file you had to do one of two things:
wine "fpga_editor mydesign.ncd"
where mydesign.ncd is the name of the .ncd
file you want to view. Basically, a command-line option to
fpga_editor appears to work if the file is in the
local directory.
Also, when running fpga_editor, you will notice errors and messages such as:
fixme:mdi:MDIRefreshMenu partially function stub err:heap:HeapValidate Heap 41700000: block ffffffff is not inside heapAgain, these are common and to be expected, though, you should see fewer of these message under Wine-20010510 than earlier versions.
Previously, with the Windows process spawning problems of Wine, programs like dsgnmgr wouldn't work at all. I have tried dsgnmgr under Wine-20000821 and Wine-20010510 and things work better, but due to OLE problems (with revengine.exe), dsgnmgr doesn't appear to be able to talk to programs that it spawns or some problem like that. If you are interested, the messages that Design Manager and Wine give, respectively, are:
The OLE initialization program: revengine.exe failed. This program is
used for inter-process communication. Please check your installation.
fixme:ole:CoCreateInstance no instance created for {00000000-0000-0000-c000-000000000046}, hres is 0x80040154
fixme:ole:CoRegisterMessageFilter stub
Makefiles and scripts are probably the best methods for building
designs under Linux.As a final note, the files generated by the Windows Xilinx tools, of course, follow the DOS/Windows file conventions--CR/LF pairs appear in the text files, for instance. For some applications, we like to make text files more Linux/UNIX compliant. In Makefiles and scripts, I often do things like the following to deal with the issue:
tr -d '\r' < x0.ll >x0.tmp.ll mv x0.tmp.ll x0_fpadd.ll
Linux PII 333 (All files retrieved over NFS)
1.480u 3.090s 5:51.61 1.2% 0+0k 0+0io 7394pf+0w
-------
Linux PIII 500 (All files retrieved over NFS)
0.940u 3.010s 5:24.94 1.2% 0+0k 0+0io 7372pf+0w
-------
HP-UX J2240 (local design files)
190.30u 10.15s 4:09.03 80.4%
-------
Linux PII 333 (local design files)
1.600u 2.840s 2:56.70 2.5% 0+0k 0+0io 7394pf+0w
-------
Linux PIII 500 (local design files)
1.020u 2.910s 1:53.01 3.4% 0+0k 0+0io 7372pf+0w
-------
Clearly, NFS on Linux is really killing us for this tiny design since
much of the time is spent actually reading and writing files. In
previous tests in which much of the time is spent computing, these I/O
related problems were not as dominant and the Linux numbers look
better even with the NFS issues.Here are some comparisons provided by other members of the lab on much larger designs:
Design: CDI (Virtex)
HP-UX J2240 (All local files), no (default?) effort level:
1 hr. 37 min.
Linux PIII 500 (local design files), no (default?) effort level:
17 min.
HP-UX J2240, highest effort level, 2 delay/2 clean-up passes:
approx. 30 hrs.
Linux PIII 500 (local design files), highest effort, 2 delay/2 clean-up passes:
29 min. 18 sec.
Design: Superquant, XC4085
Linux PIII 500
76.170u 832.670s 42:33:38.53 0.5% 0+0k 0+0io 7422pf+0w
-----------
HP-UX J2240
346142.79u 338.91s 97:17:38.16 0.8%
-----------
From these larger design, it's clear that the Xilinx tools under Linux
run quite fast even using the wine emulator. Just imagine
how fast they would be if they were compiled for Linux.
To jump start usage of the tools, new system.reg and user.reg files are available to place in your ~/.wine directory. I suggest backing up the old files before adding the new ones. Also, the files that you download may have a slightly different name than Wine expects; you need to make sure that they are named system.reg and user.reg exactly. Finally, for those at BYU, you will also need to point your C: drive in your ~/.wine/config file to point to /mirrors/usr/wine-c---this is a link pointing to the latest version of the tools. All of the other settings from Setting Up Your Environment should be fine.
Go to the CCL Home Page