Using the Xilinx Alliance 3.1i Tools under Linux

Though the Xilinx Alliance tools are not compiled for Linux, they appear to work just fine under the Wine emulator. Version 20000821 of the emulator appears to be an improvement over many previous versions, including 991212 which was our previous version of Wine. As you might expect, though, a few caveats exist when using Wine for executing the command-line and GUI-based Alliance tools.

If you would like the setup for previous versions of Wine, please visit my older WWW page.

I will briefly describe the process of setting up your environment to execute the Xilinx Alliance 3.1i tools using our current installations of the tools and wine. The setup is significantly different with the latest install of the Alliance tools and Wine, so please read these setup suggestions carefully.

Setting Up Your Environment: Alliance 3.1i

I recommend the following for your Wine setup:
  1. Set your path to point to /mirrors/usr/wine/bin. This contains the wine binaries for Linux and the new Xilinx wrapper scripts.
  2. Create a reasonable ~/.winerc file which has [Drive C] set to point to /mirrors/usr/wine-c. My .winerc file can be used as a template. You can change the references to my home directory (/fpga2/users/grahamp) with a reference to your home directory.
  3. Set up your Wine registry entries for the Alliance 3.1i tools. There are other methods, but I would recommend just copying the following to your ~/.wine directory: system.reg and user.reg. You may have to create this directory if you haven't run Wine before. (Note that these need to be named system.reg and user.reg to work so you may have to rename the files you download.)
  4. Set the XILINX environment variable to "C:\Xilinx" according to your shell:
  5. Set our LD_LIBRARY_PATH environment variable to include /mirrors/usr/wine/lib. If don't have this environment variable, create it; otherwise, just add the aforementioned path to the variable. Note: This path list is colon (:) separated much like the $PATH variable.
  6. Set your DISPLAY environment variable appropriately. Even if you are only using command-line tools, Wine still needs to connect to your display. If I find a way around this, I will let you know.

Running the Tools

With your environment setup, you should be ready to run the tools. There are a few caveats to running the tools. Here I provide a few suggestions and workarounds.

Executing a Program

We have created a wrapper script for the most commonly used Xilinx Alliance tools. A tar file, xilinx-wrappers.tar, file of these wrapper scripts are 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

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/Xilinx/bin/nt/ngdbuild
since 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.

When executing programs with wine, you will 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 yet
These are common and to be expected. They are just messages from Wine relating debugging information and partially implemented emulation code.

In the past, the biggest shortcoming of Wine as far as executing the Xilinx tools is concerned was that Wine didn't spawn other Windows programs properly. I am glad to say that this support has improved and some Windows programs are able to successfully execute other Windows programs (for example, you can actually run the Xilinx Alliance 3.1i installer under Wine now). Unfortunately, I have noticed that ngdbuild can spawn its helper programs, but, for some reason, ngdbuild doesn't appear to know that it worked. If you run ngdbuild several times it seems 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 appears to be able to spawn m1map for XC4000 designs properly now. 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, I replaced references to map in my UNIX Makefiles with m1map as a workaround for XC4000 designs. For Virtex designs, map worked just find under Wine. With Wine-20000821, apparently, you can use just map for both XC4000 and Virtex designs without any problem since the processing spawing capabilities have improved. If you start having problems with process spawning and map for XC4000 designs, you might consider 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 "make" files, 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. In previous versions of Wine, 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 is 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:

Now, with Wine-20000821, the GUI selection of files to edit works. I am sure there are some GUI-related problems, but things are working better in general.

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 heap
Again, these are common and to be expected.

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 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.

Capturing a Xilinx Install to Work with Linux

For Wine-20000821, the Java-based installation program for the Xilinx Alliance 3.1i tools actually worked. It did have some wierd GUI problems, but I was able to select the tools to install and complete the installation without any problems. I haven't been able to get the service packs to install for 3.1i yet, but we will have to see.

Speed (old numbers)

Here are some quick comparisons for run time on a single counter placed in a 4062 part. The results are provided by executing a time make on this simple design. 
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.
grahamp@ee.byu.edu
 Last modified: Thu Sep 7 13:03:55 MDT 2000