Xilinx tools on Linux

Bizarre. While the rest of the world is going to text formats like XML (even Microsoft's Visual Studio.NET now store project files as editable XML.) Xilinx decides to move to a binary format? Can anyone from Xilinx comment on the rationale for doing this?

Apparently... The ability to script flows is really quite important to a lot of folks. From what you're saying they've removed that possibility.

What is the 'broken library support' issue?

Maybe we need someone to do for the FPGA design tools world what John Cooley (DeepChip) has done for the ASIC tools world - when stuff like this happens he takes the tool vendors to task and they listen to him.

Phil

I think I'm about to try running the Win32 version under Wine - pretty sad that their Linux version is so crappy. You'd think they'd have better understanding of the Linux platform than this - maybe Xilinx should hire some of us? ;-)

Hopefully, Xilinx is working dumping this WindU crap for a better native toolkit like Qt (actually, they could do both their Windows AND Linux versions using Qt - no need for two different toolkits or a translator). Also (HINT, HINT) Xilinx needs to either statically link their binaries or they should ship the required shared libs with the package. Their download is already ~350MB, doing this would only add maybe 20MB and it would allow ISE to run on pretty-much any Linux distro out there. I'm not saying that they need to do testing on every Linux distro out there (that would be a major headache) - they could still claim that it's only supported on RedHat, but the large numbers of us who are no longer running RedHat could run their tools with much less hassle.

Phil

There are solid version control, and user support, reasons for using an ASCII project file, that can be shared between GUI and command line flows. It also has operational benefits : You use the GUI for what it is good at ( one off set-up ), and the command line when speed and removal-of-operator-error are important.

It can also save money - in this example, a user could set up in a borrowed Windows GUI, then run Linux command line, knowing the results will be (hopefully) the same.

Where I have seen moves to binary project (and design!) files in the past, that has been driven by paranoia, and an effort to reduce portability to the "others".

History shows that the minus side of this move, outweighed any plus side. Fundamental rule: Do not penalise the legitimate users!

Seems to be two possible causes : a) A novice was put in charge of the project file decision and/or b) The paranoia quotient really is going up at Xilinx [see other posts ?]

Seems there are a lot of stumbles in the V7.1 release ?

-jg

But what would they be paranoid about? Are they afraid that Altera will create a Xilinx to Altera project converter or something? Even if they did so, would it really be that big of a deal? The benefits of having a user-editable ASCII project file (which you outline) seem to greatly outweigh this risk.

Apparently.

Phil

Phil Tomson wrote: ...

Phil,

yes, it is possible to replace the GUI with a script. At least for ISE. I have not been able to figure out hot to do the same for EDK (yet).

I have attached my script. Please note this is something I am using internally and it was not meant to be flexible or easily portable.

Besides the main "comp" script you need a few setup/scripts for various tools. This is all from my USB_OTG project, so you have to search for those keywords and replace them for your project.

I think I have problems attaching files to my news post, so I uploaded them to:

Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services,

Your Partner for IP Cores, Design, Verification and Synthesis

If you run with a 2.6 Kernel, you must do as root

echo 1 >/proc/sys/vm/legacy_va_layout

Linux Memeory layout was changed in 2.6 , now pointers to memory between

0x80000000 and 0xBFFFFFFF can escape to the windows programm and ISE stumbles about some signed/unsigned problem I guess. Also the Output windows now uses more RichEdit functionality that is not yet implemented in the Wine builtin Richedit implementation. Use native RicheEdit so long.

They should talk to Codeweavers. I guess for the money Xilinx spends on WindU, they could have Codeweavers weed out a lot of Problems in Wine (and perhaps some in the Xilinx code) so that ISE would run flawless in Wine. No more need for a WindU license and a single source tree...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Phil Tomson wrote: [...]

Howdy Phil,

In the VHDL source flow, ISE creates a project file (which as you probably guessed, is text) for that synthesis tool... so if Synplify is the selected synthesis tool, a Synplify .prj file is created. When creating that .prj file, 7.1 leaves out any files that are identified as libraries in ISE, causing Synplify to immediately error out. And as if that isn't enough, ISE *obviously* knows best and refuses to run if you manually fix the Synplify .prj file (ISE complains that the Synplify .prj file was edited manually and errors out). It all worked correctly in 6.3.

And yes, the week that 7.1.0i came out, we told our FAE about these problems (along with numerous other issues).

Marc

Isn't it interesting how fast some Xilinx guys (FAEs?) jumped on the other thread about Spartan 3E being slower than Spartan 3, but we've heard nary a peep out of them about this thread?

Phil

No theory of conspiration, please,

Those guys (always helpfull and responsive) come from different areas then the guys responsible for programming...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

But running ISE in Wine is about 10x slower than running the Linux version with Wind/U. It's actually slower than running the Windows version under VMware, which surprised me.

Apparently the Wind/U royalties aren't that big a problem, since they're giving out Webpack for Linux now. I'd much rather have Wind/U than use Wine (either normally or with Wine code linked into ISE).

Eric

No conspiracy theories here...

Ah, makes sense.

I do hope Xilinx is listening. It would be great to have a native Linux ISE 7.x in the future that works well on the platform and we're just trying to help them get there.

Phil

I haven't tried it under Wine yet. However, I can tell you that the WindU version is unusable for me as it takes several _minutes_ to start up and then it takes minutes to respond to mouse clicks on various GUI elements. I have no idea why it would be that slow - it seems rather strange. I am not running anything like seti, either. My machine is a bit dated (800MHz Duron) but it shouldn't be _that_ bad. I suspect that running the windows version under Wine should be faster.

But wasn't there some indication that they were moving to a native toolkit?

Phil

You probably run a kernel before 2.6.10. A fix for the communication between the GUI and the worker programms was introduced with 2.6.10.

And Wind/U is the only X Program that doesn't like my DISPLAY variable ":0.0" and insists on ":0"...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Probably there is someting wrong with your setup. One minute seems much too long.

There were rumors about a QT port and some people (like me) spread them. No Xilinx insider objected however....

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Uwe B> There were rumors about a QT port and some people (like me) spread them.

AFAIK, all that anyone from Xilinx has said is that they are "moving away from a GUI toolkit that is encumbered with a per-seat license fee." (Neil Glenn Jacobson, on 18-Aug-2004):

That statement can be interpreted several ways. Not necessarily as a "native" toolkit, though that would seem to make sense.

Possibly they are moving to a different toolkit, but haven't yet released a version with the new toolkit, and decided to pay the royalties on Linux Webpack downloads until that release.

Or possibly they've negotiated a new license for Wind/U that lets them offer WebPack with a reduced (or zero) royalty, which is in the vendor's interest since they will keep getting royalties on ISE.

Note that Qt still would have per-seat license fees, so I don't think it's even in the running. There's a GPL license for Qt as well, but Xilinx presumably doesn't want to GPL their tools.

But surely you don't expect to preannounce such things?

Eric

That's silly, but it doesn't seem like a big problem in practice. I have a simple wrapper script I use for invoking all the Xilinx tools, which sets up environment variables and such. It just sets DISPLAY to :0, and everything works fine.

Eric

And the other thing to make sure of is that you are using a Windows native version of msvcrt.dll. That can make a dramatic difference on ISE.

Assuming you are on Linux... (though presumably this should also work on Windows)

The EDK project is run by a makefile, named system.make. So you can can build the project by typing commands like: make -f system.make netlist which builds the bitfile from HDL code, and make -f system.make program which compiles C code and inserts it into the bitfile. Those are about the only two EDK commands I use. I never use the EDK GUI. A list of commands is available with: make -f system.make Actually, I create a symbolic link ln -s system.make makefile which means I don't need to type out the "-f system.make" stuff.

Of course, that doesn't get you the project in the first place. In general, I take an existing project that is similar to what I want, copy it over, and start modifying.

This is good to know and it seems like a reasonable explanation... Turns out I'm running 2.6.3. I'll try rebooting with my old 2.4.something kernel when I get a chance.

I think that part was OK in my case.

Phil