Victor Atkinson wrote:

> Greetings,
> 
> I am currently attempting to install Xilinx ISE 6.2i on a PC running
> SuSE Linux 9.1 Pro, and would appreciate any hints or instructions
> that you might share.  I am not getting very far on my own.  According
> to the installation instructions, I load the CD and run the setup
> script (as root) as shown below:
> 
> pc-vhdl5:/media/dvdrecorder # ./setup
> 
> The setup script fails after getting to the point of running xilsetup.
>  The xilsetup error message is:
> 
> /media/dvdrecorder/xilsetup: relocation error:
> /media/dvdrecorder/bin/lin/libwinsock44.so: symbol h_errno, version
> GLIBC_2.0 not defined in file libc.so.6 with link time reference
> 
> ************ setup done! ***************


Try setting the environment variable LD_ASSUME_KERNEL=2.4.1.  This works 
for later versions of Red Hat but have not tried it on Suse.  This is 
needed for the installer and the applications in order to work with the 
newer.

Report back whether that does the trick or not.


--  Brian

salman sheikh <sheikh@pop500.gsfc.nasa.gov> wrote in message news:<capfj5$fa$1@skates.gsfc.nasa.gov>...
> Hello,
> 
> I just installed Xilinx ISE 6.2i on a Linux box and it is sluggish as 
> anything.  Does anyone know why? I am running on a P4 1.7GHz w/ 1GB of 
> RAM.  On windows, it is much more zippy. Could it be the gui toolkit 
> that Xilinx is using (it seems like JAVA.......slow as a slug....)?
> 
> Thanks.
> 
> 
> Salman

Greetings,

I am currently attempting to install Xilinx ISE 6.2i on a PC running
SuSE Linux 9.1 Pro, and would appreciate any hints or instructions
that you might share.  I am not getting very far on my own.  According
to the installation instructions, I load the CD and run the setup
script (as root) as shown below:

pc-vhdl5:/media/dvdrecorder # ./setup

The setup script fails after getting to the point of running xilsetup.
 The xilsetup error message is:

/media/dvdrecorder/xilsetup: relocation error:
/media/dvdrecorder/bin/lin/libwinsock44.so: symbol h_errno, version
GLIBC_2.0 not defined in file libc.so.6 with link time reference

************ setup done! ***************

I have confirmed that I do have libc.so.6 in the /lib directory (also
in /lib/i686 and /lib/tls).  However, I cannot verify if my libc.so.6
has a symbol h_errno exported.  I am running glibc version 2.3.3-97,
installed from the SuSE installation media, and with all current
patches applied.

Any help that you could provide would be appreciated.  (I understand
that Xilinx doesn't claim to support SuSE for ISE, so haven't called
their support yet.  Perhaps after the holiday weekend.)

Thanks.

Victor Atkinson
Syracuse, NY

On 24 Jun 2004 12:03:33 +0100, Martin Thompson
<martin.j.thompson@trw.com> wrote:

>> 
>> You can get to the exit status in dos-ish command shells with
>> %ERRORLEVEL%.
>> 
>
>Indeed - that's what I was doing, but in my experiment, XST returned
>the same errorlevel whether it succeeded or failed... I must have done
>something wrong somewhere, I'll investigate more when I have some time...
>
>Thanks for confirming what I thought *should* happen!

I just tested xst 6.2.03i.  It returned 0 for success and 1 for
failure.


C:\>c:\Xilinx62\bin\nt\xst.exe -ifn no_file
Release 6.2.03i - xst G.31a
Copyright (c) 1995-2004 Xilinx, Inc.  All rights reserved.
ERROR:Xst:427 - Entry File no_file not found

C:\>echo %ERRORLEVEL%
1

C:\>

Regards,
Allan.

Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes:

> Martin Thompson wrote:
> >>Interesting.  I did not know about this.  I generally use XFlow on
> >>Solaris and now Linux so I have not encountered this.  For UNIX
> >>machines, it creates an xflow.scr file which is a CSH script of all of
> >> the commands however I personally never use it.
> > Ahh, my understanding of the way it worked was that the script was
> > created and then executed by the XFLOW executable, rather than that
> > executable doing all the execs itself..
> 
> 
> Not at all.  The bat file is supposed to be more for reference than
> for use in my opinion.  There is a lot of "smarts" in the tool that
> would not happen if it was used in that way.  

Yes, I thought the smarts were captured each time it was run in the
batch file.. is that right?

> It is a shame they named
> that file xflow.bat and I am going to suggest they rename it to
> something like xflowbat.bat to get around the problem you cite.
> 

That would be good!

Thanks,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> writes:

> On 23 Jun 2004 11:36:48 +0100, Martin Thompson
> <martin.j.thompson@trw.com> wrote:
> 
> >Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes:
> >
> >> In my experience however, most programs
> >> do specify non-zero error codes when an error occurs and if you
> >> properly catch them, you can abort the script execution yourself.
> >> When I used CSH as my main scripting language to run the tools, I use
> >> to do it like:
> >
> ><snip>
> >
> >> That almost never failed me but it has been a while since I have run
> >> the tools in this manner.
> >> 
> >> 
> >
> >Maybe things are different in a Windos cmd.exe shell...  I'll have to
> >look into this some more.
> 
> I'm currently doing this with Make, which interprets non-zero exit
> status as an error.
> I've previously done this with bash, with the 'set -e' option, which
> causes bash to exit whenever a command exits with non-zero status.
> 
> You can get to the exit status in dos-ish command shells with
> %ERRORLEVEL%.
> 

Indeed - that's what I was doing, but in my experiment, XST returned
the same errorlevel whether it succeeded or failed... I must have done
something wrong somewhere, I'll investigate more when I have some time...

Thanks for confirming what I thought *should* happen!
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Martin Thompson wrote:
>>Interesting.  I did not know about this.  I generally use XFlow on
>>Solaris and now Linux so I have not encountered this.  For UNIX
>>machines, it creates an xflow.scr file which is a CSH script of all of
>>the commands however I personally never use it.  
> 
> 
> Ahh, my understanding of the way it worked was that the script was
> created and then executed by the XFLOW executable, rather than that
> executable doing all the execs itself..


Not at all.  The bat file is supposed to be more for reference than for 
use in my opinion.  There is a lot of "smarts" in the tool that would 
not happen if it was used in that way.  It is a shame they named that 
file xflow.bat and I am going to suggest they rename it to something 
like xflowbat.bat to get around the problem you cite.


--  Brian



<snip>

On 23 Jun 2004 11:36:48 +0100, Martin Thompson
<martin.j.thompson@trw.com> wrote:

>Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes:
>
>> In my experience however, most programs
>> do specify non-zero error codes when an error occurs and if you
>> properly catch them, you can abort the script execution yourself.
>> When I used CSH as my main scripting language to run the tools, I use
>> to do it like:
>
><snip>
>
>> That almost never failed me but it has been a while since I have run
>> the tools in this manner.
>> 
>> 
>
>Maybe things are different in a Windos cmd.exe shell...  I'll have to
>look into this some more.

I'm currently doing this with Make, which interprets non-zero exit
status as an error.
I've previously done this with bash, with the 'set -e' option, which
causes bash to exit whenever a command exits with non-zero status.

You can get to the exit status in dos-ish command shells with
%ERRORLEVEL%.

Regards,
Allan.

Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes:

> Martin Thompson wrote:
> 
> > When I tried XFLOW, it seemed to want to create a batch file called
> > xflow.bat with all the commands in it that needed running.  Next time
> > I typed an XFLOW command, all it did was run the old xflow.bat from
> > the current directory.  That had me bemused for a long time - i take
> > it everyone that uses it does so on Unix (where . isn't on the path
> > like it is in windos land).
> 
> 
> Interesting.  I did not know about this.  I generally use XFlow on
> Solaris and now Linux so I have not encountered this.  For UNIX
> machines, it creates an xflow.scr file which is a CSH script of all of
> the commands however I personally never use it.  

Ahh, my understanding of the way it worked was that the script was
created and then executed by the XFLOW executable, rather than that
executable doing all the execs itself..

> You can also have it write out the script in TCL if you prefer.  If
> you want, that script can be used to integrate into other scripts or
> used stand-alone if you want to get away from the xflow "shell".
> Similarly for the .bat file on a PC but I guess it has this
> interesting side effect.  I will pass this on to that group so that
> they can evaluate how to get around that problem. Thanks for the
> feedback.
> 
> 
> > Speaking of batch file processes - does anyone know how to find out
> > if
> > XST generated any errors - in my experiments, it returns the same
> > ERRORLEVEL every time.
> 
> 
> Don't know about this.  I just tried to run XST from xflow where I
> introduced a syntax error into one of my Verilog files and got back
> the response:
> 
> ERROR:Xflow - Program xst returned error code 6.  Aborting flow execution...
> 
> There it looks like XST is specifying an error code that you could key
> off of.  Perhaps it is specific to the error or situation you have
> created.
> 
> 

Hmmm, more experimentation required at my end then - thanks for the
counter-example.

> 
> > I'm sure I've seen this with other tools as well, which means that the
> > compilation runs through to completion on the old files!  One
> > hackaround I've seen from a reputable source is to do your
> > implementation in a clean directory every time, copying in the UCF,
> > EDF eetc.  But that seems nasty!
> 
> 
> You could start each run in a clean directory or else build into your
> script to smarts to either move some of the relevant input files to
> the next portion of the flow into another directory (backup of
> previous run) or else just delete them.  That way when you get to the
> next program, it should error out saying file not found if you did not
> catch the error code before.  

I could, but it doesn;t feel like the "right way" to do it.

> In my experience however, most programs
> do specify non-zero error codes when an error occurs and if you
> properly catch them, you can abort the script execution yourself.
> When I used CSH as my main scripting language to run the tools, I use
> to do it like:

<snip>

> That almost never failed me but it has been a while since I have run
> the tools in this manner.
> 
> 

Maybe things are different in a Windos cmd.exe shell...  I'll have to
look into this some more.

Thanks,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Martin Thompson wrote:

> When I tried XFLOW, it seemed to want to create a batch file called
> xflow.bat with all the commands in it that needed running.  Next time
> I typed an XFLOW command, all it did was run the old xflow.bat from
> the current directory.  That had me bemused for a long time - i take
> it everyone that uses it does so on Unix (where . isn't on the path
> like it is in windos land).


Interesting.  I did not know about this.  I generally use XFlow on 
Solaris and now Linux so I have not encountered this.  For UNIX 
machines, it creates an xflow.scr file which is a CSH script of all of 
the commands however I personally never use it.  You can also have it 
write out the script in TCL if you prefer.  If you want, that script can 
be used to integrate into other scripts or used stand-alone if you want 
to get away from the xflow "shell".  Similarly for the .bat file on a PC 
but I guess it has this interesting side effect.  I will pass this on to 
that group so that they can evaluate how to get around that problem. 
Thanks for the feedback.


> 
> Speaking of batch file processes - does anyone know how to find out if
> XST generated any errors - in my experiments, it returns the same
> ERRORLEVEL every time.


Don't know about this.  I just tried to run XST from xflow where I 
introduced a syntax error into one of my Verilog files and got back the 
response:

ERROR:Xflow - Program xst returned error code 6.  Aborting flow execution...

There it looks like XST is specifying an error code that you could key 
off of.  Perhaps it is specific to the error or situation you have created.



> I'm sure I've seen this with other tools as well, which means that the
> compilation runs through to completion on the old files!  One
> hackaround I've seen from a reputable source is to do your
> implementation in a clean directory every time, copying in the UCF,
> EDF eetc.  But that seems nasty!


You could start each run in a clean directory or else build into your 
script to smarts to either move some of the relevant input files to the 
next portion of the flow into another directory (backup of previous run) 
or else just delete them.  That way when you get to the next program, it 
should error out saying file not found if you did not catch the error 
code before.  In my experience however, most programs do specify 
non-zero error codes when an error occurs and if you properly catch 
them, you can abort the script execution yourself.  When I used CSH as 
my main scripting language to run the tools, I use to do it like:

    ngdbuild $NGDBUILD_OPTIONS $part $ucf $ngdinput >&! ngdbuild.log

    if ($status != 0) then
       echo "Ngdbuild did not successfully finish, do you wish to"
       echo "check ngdbuild.log for errors."
       echo -n " Y/N : "
       set ans = $<
       set ans = `echo $ans |sed -e 's/ *$//'`
       if ( "${ans}" =~ [Yy] ) then
          less ngdbuild.log
       endif
       exit(1)
    endif

That almost never failed me but it has been a while since I have run the 
tools in this manner.


--  Brian

Hal Murray wrote:

> There are two parts to makefiles.  One is the sequence of commands
> needed to recreate something.  The other is that is collects all
> the parameters/options/flags in one place.  Most software geeks
> consider the makefile to be a source file and include it with the
> other source files in some sort of source-code control system.
> 
> Does xflow (and friends) have a single file where that sort of info
> is collected?
> 

Yes, similar but it is slightly different from the general make file 
process.  Xflow will create a .flw and that will list all intermediate 
programs that need to be run to complete all flows.  It lists the 
executable name, all input, output and trigger files as well as the 
report files.  The file is pretty much self-documented but there is more 
on it in the manual if you need to learn more.  There are also .opt 
files produced or can be hand-written if you want to create a unique 
flow.  The .opt file does two things.  It tells which programs need to 
be run for a particular flow and allows you to set all individual 
options for a particular sub-program.  For instance, if you want to run 
the -mhf switch for netgen (will write out a separate timing netlists 
and SDF for each level of hierarchy in the design), then you can do this 
in the opt file for the -tsim switch.  To take my first example again:

xflow -implement high_effort -tsim modelsim_verilog <design>.edf

If you run this command, an fpga.flw file will be created that will list 
all sub-programs (i.e. ngdbuild, map, par, etc.) necessary for an FPGA 
flow.  If you want to add another program, say you want to automatically 
open floorplanner at the end of a run or you want to run your simulator 
for a timing simulation, you can add those programs to this file if you 
want however the general flow programs are all there already for you. 
This command-line will also create two .opt files, high_effort.opt and 
modelsim_verilog.opt.  Those files will list the sub-programs necessary 
to run a high effort implementation run in the order they need to be 
run.  It also lists all of the default options for the individual 
programs and allows you to modify or add addition options if you so 
choose.  Similarly, the modelsim_verilog.opt file lists the programs to 
create a Verilog timing simulation netlist for ModelSim as well as all 
of the suggested options for that flow.  This is where you would add the 
-mhf switch I mentioned above to the netgen section of this file if you 
wanted that capability added to the flow.  If you want to complete the 
custom execution of floorplanner after the run or the running of the 
simulator after creating the timing simulation netlist, you would add 
those calls to these .opt files.  Again, the .opt files are fairly 
intuitive, generally you can have xflow create the initial files for 
your run and then you make minor modification if necessary to get 
exactly what you want.

Xflow is fairly easy to use and that reason alone is a good enough for 
me to use it but the other benefit it provides, even if you use other 
scripting methods is that it somewhat shields you from the minor 
differences/changes than happen to individual tools in the flow as 
enhancements are made.  As recommended defaults change, as switches are 
added to reveal new capabilities and as flows change to address new 
design, implementation and verification methodologies, xflow adjusts to 
this, not you adjusting your hand-crafted make/CSH/Perl. etc. script. 
That exact same command above could run the 4.1i tools as it does the 
6.2i tools today however if you created your own script to run the 
individual tools, some adjustments would likely need to be made to do 
the same.  Or lets say you have now added equivalence checking to your 
verification methodology, all you would need to do is add the "-ecn 
formality_verilog" switch to the above execution and an equivalency 
checking netlists will also be produced.  Again, it would be more 
difficult to add this capability to a custom script to run the 
individual programs.

Try it out.  I would be interested to hear your feedback on it.

--  Brian