Xilinx tools on Linux

Duane Clark wrote:

> I found that behavior if I have, for example, setiathome running in the 
> background. Even renicing seti to priority 19 did not help. I would 
> suggest checking for processor intensive tasks running in the background.

Thanks, that led me to stop the distributed.net background task, and the 
GUI went from sluggish (though only just usable) to quite snappy.

Lawrence

In article <1113761592.889108.25670@f14g2000cwb.googlegroups.com>,
Marc Randolph <mrand@my-deja.com> wrote:
>
>Phil Tomson wrote:
>> In article <d3s0co$4mj$1@lnx107.hrz.tu-darmstadt.de>,
>> Uwe Bonnes  <bon@elektron.ikp.physik.tu-darmstadt.de> wrote:
>> >Phil Tomson <ptkwt@aracnet.com> wrote:
>> >
>> >> Well, it turns out the the ISE GUI is unusable for me - it takes
>up to
>> >> several minutes to respond to mouse clicks.
>> >
>> >> However, I'd actually prefer to be able to script the whole thing.
> I know
>> >> that a while back someone posted a link to a webpage that showed
>how to
>> >> run the Xilinx tools from the command line but now I can't find it
>even
>> >> via goodle.
>> >> Anyone got the link?
>> >
>> >Loo at the <projectname>.cmd_log file after a successfull run of the
>> >GUI. You see all commands executed.
>>
>> Well, I haven't had a successful run of the GUI yet.  I'll have to
>look
>> at it on a Windows machine at school.
>>
>> BTW: is it possible to set up the project without the GUI?  I'm
>assuming
>> it's just some sort of text file (the project file).
>
>Howdy Phil,
>
>   It used to be.  The GUI group appears to have gone to binary project
>file, at least on Windows version of ISE 7.1i - that move alone has
>almost driven me away from using the VHDL flow, back to using the edif
>flow.  

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?

> Add the broken library support in the 7.1i VHDL flow, and it's
>really case closed.  Stuff like this really drives home the fact that
>the developers must not use or view the tools in the the same way as
>their users do.

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

In article <d3uipi$bvg$1@ucsnew1.ncl.ac.uk>,
Martin Ellis  <me_ncl@hotmail.com> wrote:
>David wrote:
>
>Incidently, the GUI actually behaves nicer running when running the Win32
>version under WINE than using the Motif based version.  Sigh.
>

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

Phil Tomson wrote:
> In article <1113761592.889108.25670@f14g2000cwb.googlegroups.com>,
> Marc Randolph <mrand@my-deja.com> wrote:
>>Howdy Phil,
>>
>>  It used to be.  The GUI group appears to have gone to binary project
>>file, at least on Windows version of ISE 7.1i - that move alone has
>>almost driven me away from using the VHDL flow, back to using the edif
>>flow.  
> 
> 
> 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?

  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

In article <4262f6e4$1@clear.net.nz>,
Jim Granville  <no.spam@designtools.co.nz> wrote:
>Phil Tomson wrote:
>> In article <1113761592.889108.25670@f14g2000cwb.googlegroups.com>,
>> Marc Randolph <mrand@my-deja.com> wrote:
>>>Howdy Phil,
>>>
>>>  It used to be.  The GUI group appears to have gone to binary project
>>>file, at least on Windows version of ISE 7.1i - that move alone has
>>>almost driven me away from using the VHDL flow, back to using the edif
>>>flow.  
>> 
>> 
>> 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?
>
>  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 ?]

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.

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

Apparently.

Phil

Phil Tomson wrote:
...
> Well, I haven't had a successful run of the GUI yet.  I'll have to look
> at it on a Windows machine at school.
> 
> BTW: is it possible to set up the project without the GUI?  I'm assuming
> it's just some sort of text file (the project file).
> 
> Phil

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:
http://www.asics.ws/ise/

Best Regards,
rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Phil Tomson <ptkwt@aracnet.com> wrote:

> 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 

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.

> - maybe Xilinx should hire some of us? ;-)

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

> Hopefully ...

-- 
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:
[...]
>
> What is the 'broken library support' issue?

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

In article <d3vt99$iia$1@lnx107.hrz.tu-darmstadt.de>,
Uwe Bonnes  <bon@elektron.ikp.physik.tu-darmstadt.de> wrote:
>Phil Tomson <ptkwt@aracnet.com> wrote:
>
>> 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 
>
>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.
>
>> - maybe Xilinx should hire some of us? ;-)
>
>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...
>
>> Hopefully ...
>

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

Phil Tomson <ptkwt@aracnet.com> wrote:

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

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