Though the Xilinx Alliance tools are not compiled for Linux, many of the tools appear to work just fine under the Wine emulator. Version 991212 of the emulator appears to be better in most respects than previous versions and only a few caveats exist when using Wine for executing the command-line Alliance tools.
In the BYU Configurable Computing Laboratory, we have been using Linux to process designs since December 1999 with the Xilinx Alliance 2.1i tools and Service Pack 3. This arrangement has been very stable for Xilinx XC4000 designs. Unfortunately, some Virtex designs seem to cause memory problems in Wine so we cannot process these particular designs under Linux using Wine; other Virtex designs appear to have no problems at all under Wine. As of April 2000, we have been trying Service Pack 6, but we cannot report much on the stability of the tools at this point.
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 the number of contracted Xilinx licenses to stay legal and supported. This information should be in no way used to circumvent or ignore the license agreements for Xilinx software.
I will first discuss why you might want to try this approach out to process Xilinx designs. Next, I will describe how to capture a Xilinx install to work with Linux and then I will briefly describe the process of setting up your environment to execute the Xilinx Alliance 2.1i tools using that installation and wine. After this explanation, I will provide some hints on how to execute the Xilinx tools using Wine and what will not currently work with Wine. Lastly, I provide some execution times for generating Xilinx designs under Wine.
Another option, of course, would be to run VMWare instead of Wine under Linux. The tools should run faithfully under Linux in that scenario, but this approach, of course, costs more (Wine is free while VMWare isn't) and I would expect VMWare to require more resources and overhead than running Wine, meaning the command-line tools might run faster under Wine.
fixme:win32:PE_LoadImage FATAL: Need to relocate c:\temp\something.exe, but no relocation records present (stripped during link). Try to run that file directly !If you then simply kill the current process and then execute the specified file directly, then the installation will resume. (If I remember right, you actually have to kill the process instead of exiting gracefully so the installation application doesn't do any clean-up. It has been a while, though, so killing the install application may not be necessary.) In the case where you can install the Xilinx tools directly under Wine, you will not need to worry about capturing registry settings and importing them into your Wine environment--they will be contained in your ~/.wine/system.reg and ~/.wine/user.reg.
With version 2.1i, the installer is Java-based, which should make things easier, but it didn't. So, as an alternative, I installed under NT, used tar to consolidate the installation directory into a single file, grabbed the Xilinx entries for the NT registry and all appears to be well. I also tried directly using jar to unpack the entire installation, but clearly some files are created or modified by the installation process since this approach did not work---the Xilinx tools complained that the installation was broken. A Java-based install method might still work, but I didn't have enough time to force the issue.
To be more specific about how to capture the Xilinx registry settings when installing under Windows, you basically use regedit to capture the entire Windows registry before the installation; for instance, you can call the registry before installation before.reg. Then, install the Xilinx tools under Windows as you normally would. Next, use regedit again to capture the entire Windows registry, naming the file something like after.reg. Now follow the process described in the README file for the regapi program that comes with Wine. The process performs essentially a "diff" of the two registries and creates a third registry file which can be merged into a Wine user's existing registry settings. Note that I believe you must execute the "registry diff" shell scripts described in the README from /usr/local/bin or whatever directory in which they are located if you want to create your own "registry diff" file; the shell scripts do not appear to be very smart about search paths for executables. We will discuss how to use this "registry diff" below.
Note that as you apply Service Packs to your Xilinx installation under Windows, you might need to perform this same "registry diff" process described above to maintain the same registry settings under Wine. It has been our experience that the Service Packs do not make any significant changes to the registry settings, meaning that we haven't had to do anything to our Wine registries to run the new Service Packs.
With this said, I recommend the following for your Wine setup:
/usr/local/bin/regapi -force setValue < xilinx.reg.toAddThe -force option forces the registry settings to be updated even if they already exist. Note that xilinx.reg.toAdd must be modified to reflect your own Serial Number and CD Key. If you created your own "registry diff" file, as described in Capturing a Xilinx Install to Work with Linux above, you can use this file instead of my xilinx.reg.toAdd. As I mentioned above, I believe you must execute the "registry diff" shell scripts from where ever they are installed (they are not very smart about paths) if you want to create your own xilinx.reg.toAdd. Also, I believe regapi must be run from a directory or subdirectory known to Wine and you must have a valid Wine setup (~/.winerc, etc.). For further information, check out the README.regapi file which comes with the standard wine distribution in the programs/regapi subdirectory.
setenv XILINX "G:\Xilinx-2.1i"
wine ngdbuildIf you need to execute a Windows program with arguments (as we often need to do), you need to enclose the command and its arguments in double or single quotes. 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"For the curious, here's a screenshot of fpga_editor working under Wine with the -managed flag.
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 /usr/local/cad/Xilinx-2.1i/bin/nt/ngdbuildsince it can do the translation to the Windows world, assuming the subdirectory is defined in the Wine environment (check the .winerc file for that). 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.
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 big shortcoming of using Wine to execute the Xilinx tools under Linux is that Wine cannot currently spawn other Windows programs in the Wine environment. What this means is that for programs like ngdbuild and map which call other programs, you will have to execute these other programs explicitly. For instance, with the Wildforce environment, there are a few XNF drop-ins or subdesigns. 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 explicitly before calling ngdbuild. Note that your main design file must be translated as well as drop-ins or other subdesigns before executing ngdbuild.
I have noticed that map actually calls m1map for XC4000 designs, while it doesn't for Virtex. In converting my UNIX Makefiles to handle the Wine environment, I have replaced references to map with m1map for XC4000 designs and had no problems. For Virtex designs, map should be used as usual.
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 "make" files, but it can be handled fairly easily if you know of the problem beforehand.
As a reminder, it is also worth noting that the text files created by Wine are Windows/DOS text files, meaning that they have "\r" characters at the end of each text line. These can be converted to UNIX-style text files by simply executing:
tr -d "\r" < windows.file.txt > unix.file.txtAnother problem I have noticed is the dialogs for choosing a file to view with fpga_editor don't really work. The file of interest appears to be appropriately entered in the dialog box once selected, but can't actually be viewed unless it is in the root directory for the emulated Windows drive. If you would really like to view a file you can 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.
Considering the problem with not being able to spawn other Windows programs in the Wine environment, don't expect the dsgnmgr to work at all.
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. (Hint, Hint, Xilinx!!)