"Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl> writes:

> > I think it's wrong to check for the distribution. One should check for
> > the functionality required by the tool. If you require a certain
> > thread library, check for that and report that installation fails
> > since the specific thread library is not present.
> 
> The trouble is that you can check for version numbers and such, but not on
> actual capabilities when you get a distribution shoved in your face. Red Hat
> 9.0 reports a certain version number for their Posix threads library that is
> basically the same as the version number reported by the 8.x versions.
> However, this 9.0 version uses significantly different kernel calls than the
> 8.x series. How to determine what a library does under the hood... If you've
> got a good idea that does not involve compiling code and see whether it
> coredumps, I'll take it.

Hi Ben,

Unfortunately I don't have a lot of Posix threads experience so I
can't comment on the version number checking. However, I think one
should check for the functionality provided by the different versions
rather than trying to extract their version numbers.

It might be possible to fork out two pre-compiled code segments which
assume the functionality of the two thread libraries. One will crash
(I guess you'll have to catch that sigv) and not return the correct
result. The other will run and return the correct result. This way you
should be able to tell which part of the installer has to use. Of
course testing for a known kernel bug which will lock up the machine
this way is not advisable :-)

OTOH I don't see why compiling a small program and see if it compiles,
links, and run is that bad. This is what's taking place in the GNU
autoconf script which many Linux users are quite familiar with.


> IMHO, Quartus under Linux is pretty flexible when it comes to
> distributions.

Yes. But unfortunately it does not run on the x86-64 under SuSe 8.2 as
I mentioned in an earlier message. I think it will run if the
LD_LIBRARY_PATH etc. is set up correctly. This is a minor issue which
I think would be simple to fix.

I don't think Altera should officially support all (or a large number
of) Linux distributions. I think it's better to make sure it runs well
under the officially supported version. 

However, I hate to see software which checks if /etc/redhat-release
matches a given string and bails out if it doesn't (it could give you
a warning that you're running under a non-supported release). Again,
they should check for the functionality required by the tool so that
it could run under multiple distributions which provide the same
libraries as the officially supported version. I think this will only
get better over time as Linux becomes even more mainstream in the EDA
world.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hi Petter,

> I think it's wrong to check for the distribution. One should check for
> the functionality required by the tool. If you require a certain
> thread library, check for that and report that installation fails
> since the specific thread library is not present.

The trouble is that you can check for version numbers and such, but not on
actual capabilities when you get a distribution shoved in your face. Red Hat
9.0 reports a certain version number for their Posix threads library that is
basically the same as the version number reported by the 8.x versions.
However, this 9.0 version uses significantly different kernel calls than the
8.x series. How to determine what a library does under the hood... If you've
got a good idea that does not involve compiling code and see whether it
coredumps, I'll take it.

IMHO, Quartus under Linux is pretty flexible when it comes to distributions.
I've been using Quartus using Gentoo Linux on a 2.6.0-testX-mmY kernel for
the last few months and I haven't had a single problem so far. The main
issue that Altera has with Linux distros is supportability - which I have
waived ;-) There's only so much useful Linux knowledge you can cram into a
support engineer in any given timespan to solve issues, and I think that
they made a fairly good, (maybe slighly US-centric) choice.

Best regards,


Ben

Hello:
 I am not so surprised: this thread, has triggered lots of answers.

To me, this underline the need, for a given Linux application to be
able to run on most "current" distributions. Or stated otherwise to be
distribution independent.

If Altera (or any other vendors) do not want to do this, it is after
all their choice to loose customers to vendors who will address waht
seems to be a very common request. But I believe their concern is to
have to test, and support their software on only one distribution, to
make things possible.

Instead of having the (irrational in my view) position: "We support
only this Linux" which inevitably will result in supporting the local
Linux vendor (SUSE=Germany, REDHAT=US, MAndrake-France, etc...), I
would suggest to rather  support a "level" of Linux Kernel+Libraries.

A collateral advantage, would be for libraries and kernel developpers
to evaluate if they did not break backward compatibility, by trying a
few large applications.

In my view it is fine for vendor to test their distribution, only on
one current version of Linux. (Current to me is latest and one before
latest).
I would advocate to use Debian, which is based on stability, rather
than "bleeding edge", and is really open source. Unless I am mistaking
it also uses unmodified Linux Kernels. (Commercial distributions tend
to modify the kernel).

This will have the advantage to have Linux deliver what most of US
want: freedom of choice, unlike proprietary operating systems.

To achieve this, could be either a fancy script, but I have to admit
that I do not favor this: 1) portablility is not great, 2) Debugging
can be hairy.

I am wondering if the best solution would not be, just a simple open
source module written in C, which could do the necessary
initialization (checking authorizations, setting of environment
variables, openning of configuration files), and having this open
source module, calling "Proprietary code" in object form.

This would allows user to develop and post on the net fancy
installation files, specifics to a given distribution.
Does this make sense?

Thanks for your attention.
----
Jan De Ceuster <jandc@elis.ugent.be> wrote in message news:<bn59aj$tqj$1@gaudi2.UGent.be>...
> >>And now it works... Maybe Altera should write a cleaner script that
> >>first checks if it's a Red Hat distribution...
> > 
> > 
> > Yes. But it would have been even better if they checked for the
> > *features* they need rather than checking the distribution.
> 
> Indeed and I even had to manualy add some directories to the librarypath to get 
> everything up and running. It just doesn't look profecional to me. 2 days work 
> (at most) for a decent engineer and the scripts would have been perfect. I'm a 
> bit dissapointed...
> 
> kind regards,
> Jan

"Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl> writes:

> Trouble with all this distribution stuff is that there is no defined
> standard that tells you how to determine which distribution a system is
> running on. Even doing an "ls -l /etc | grep *release" will not give you the
> full info, because every distro puts different things into these files, plus
> they may have, for example redhat-release and lsb-release, containing
> different data structures. Determining the kernel version and/or glibc
> version is useless (Suse 9.0 reports 2.4.21-99 or so), glibc versions may or
> may not have NTPL support using the same version number and more of that
> stuff. Really messy.

I think it's wrong to check for the distribution. One should check for
the functionality required by the tool. If you require a certain
thread library, check for that and report that installation fails
since the specific thread library is not present.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Jan De Ceuster" <jandc@elis.ugent.be> wrote in message
news:bn59aj$tqj$1@gaudi2.UGent.be...
> >>And now it works... Maybe Altera should write a cleaner script that
> >>first checks if it's a Red Hat distribution...
> >
> >
> > Yes. But it would have been even better if they checked for the
> > *features* they need rather than checking the distribution.
>
> Indeed and I even had to manualy add some directories to the librarypath
to get
> everything up and running. It just doesn't look profecional to me. 2 days
work
> (at most) for a decent engineer and the scripts would have been perfect.
I'm a
> bit dissapointed...

Never needed to do this - and I'm running Gentoo Linux, an utterly
unsupported (but rather good) distribution. It just runs out of the box.
I've been working on Altera's system identification scripts in the past.

Trouble with all this distribution stuff is that there is no defined
standard that tells you how to determine which distribution a system is
running on. Even doing an "ls -l /etc | grep *release" will not give you the
full info, because every distro puts different things into these files, plus
they may have, for example redhat-release and lsb-release, containing
different data structures. Determining the kernel version and/or glibc
version is useless (Suse 9.0 reports 2.4.21-99 or so), glibc versions may or
may not have NTPL support using the same version number and more of that
stuff. Really messy.

I think that if Altera could find a waterproof way of figuring out which
distribution and version of it it's running on, plus its capability model,
it would be worth a patent, even if they didn't apply for it ;-)

If you have any tips (including just mentioning which directories you still
had to add), you're welcome to post them.

Best regards,


Ben

Hi Andre,

> 4) Suse 9.0: did anyone try?

I did try Suse 8.1, 8.2 and 9.0, and in allcases it failed at an unexpected
point. GUI came up nicely and stuff, and for MAX devices you'll get some
wonderful results, but for SRAM-based devices, something is going wrong.
Someone within development is looking at this though, and I have his phone
number...

Best regards,



Ben

Followup to:  <87smljd8i6.fsf@zener.home.gustad.com>
By author:    Petter Gustad <newsmailcomp6@gustad.com>
In newsgroup: comp.arch.fpga
>
> uselinux2000@yahoo.com (linux user) writes:
> 
> 
> >    Altera has very talented engineers, and there is no doubt in my
> > mind that very soon a nice install, possibly similar to the one of
> > Open Office (GUI based) will be available for Linux.
> 
> I've been a Linux user since 1993 and I'm very happy to see that Linux
> support from the major FPGA vendors is improving.
> 
> However, I would like Altera and Xilinx to spend their efforts on other
> things than a GUI based install program. I recall all the problems I
> have had over the years with the Xilinx GUI based install program
> under Solaris. It would sit there for days flashing cute ads without
> installing anything :-( A simple tar would done the job. Of course you
> most likely need a way of specifying which devices and parts to
> install, but that's about it. Sometimes I install Linux software on
> file servers which don't even have X11.
> 

Indeed.  Most Linux users would vastly prefer one or more RPMs which
"just work" once installed.  Interactive install is not a good thing.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

"Subroto Datta" <sdatta@altera.com> writes:

>  Your 2 cents and several more from our customers big and small, have added
> up to a full dollar. Take a look at AN 312:
> http://www.altera.com/literature/an/an312.pdf

Thank you for the link. I've read some previous documentation on
Quartus scripting, but I have not seen this one yet.

> which is fully supported in Quartus II 3.0.  This is the new Tcl API which
> Altera will support, document and add to going forward. It addresses the

It looks like Altera is going in the right direction. 

> and the parameters to these functions have a -keyword <value> syntax. They
> are not position dependent anymore. To make it easy for new users to learn

Great. Are all the assignment keywords documented anywhere?

If not in some cases it would have been easier to have a command
wrapper around the setting. I used the APP note as a guide to write an
improved quartus_sh script. I'm adding files using:


foreach f $flist {
    set_global_assignment -name VERILOG_FILE $f
}

My problem is that most of the files will include another. So I get an
error saying that it can't find the include file. I had no idea what
the assignment name for this command was. If it was a command I could
have done "info commands" and search through the output and guess
which one did the job and run it with a -help argument to learn about
its parameters etc.

The way I figured out was to launch the GUI and generate a TCL script
to learn that the -name option I was looking for was USER_LIBRARIES...


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Petter,

 Your 2 cents and several more from our customers big and small, have added
up to a full dollar. Take a look at AN 312:
http://www.altera.com/literature/an/an312.pdf
which is fully supported in Quartus II 3.0.  This is the new Tcl API which
Altera will support, document and add to going forward. It addresses the
issues you have mentioned below. The old API will also be supported for
backwards compatibility, but it is recommended that new projects use the new
Tcl API exclusively.

We have added more functions than the ones listed in App Note 312 for the
next version of Quartus. Some of these are:
project_new
project_open
is_project_open
project_close
project_exists
project_archive
project_restore
set_project_settings
get_project_settings
project_settings_exist
set_parameter
get_parameter
get_all_parameters
set_global_assignment
get_global_assignment
get_all_global_assignments
set_instance_assignment
get_instance_assignment
get_all_instance_assignments
set_location_assignment
get_location_assignment
export_assignments
create_base_clock
create_relative_clock
foreach_in_collection
set_multicycle_assignment
set_timing_cut_assignment

and the parameters to these functions have a -keyword <value> syntax. They
are not position dependent anymore. To make it easy for new users to learn
this API, the entire Quartus Project can be written out as a Tcl script (of
course from the GUI :-), archived and used to recreate the project from
scratch each time.

Regards,

Subroto Datta
- Altera Corp.


"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message
news:87oew7d5zt.fsf_-_@zener.home.gustad.com...
> Petter Gustad <newsmailcomp6@gustad.com> writes:
>
> > I would rather have better scripting capabilities, support for
>
> I prefer to have my scripts under a source control system to be able
> to generate reproducible results. Not a designs which accidentally did
> or did not work because somebody on the project checked off an option
> several levels down in a GUI dialog box(1) (if DUI is "driving under
> influence", what is GUI?). For floorplanners and waveform viewers I
> use GUI's, but for plain synthesis, place and route, etc. I prefer
> scripts.
>
> I would like to say that Altera have spend quite a bit of effort
> putting scripting capabilities into Quartus. Quartus have TCL support,
> but the way you write your "code" is kind of weird:
>
> project add_assignment $top "" "" $clk GLOBAL_SIGNAL ON
>
> In order to check that the command had succeeded you have to check if
> the above command returned something like "assignment made". It also
> seems that the names and values for the various assignments might
> change from different Quartus releases.
>
> In later versions of Quartus Altera has added several smaller tools
> which do synthesis and elaboration, place and route, timing analysis,
> etc. This is good, even though I can't really see why bash is more
> suited than TCL to run the various commands/tools (assuming you make
> tclsh do dynamic linking).
>
> However, these tools seem to use a CSF (compiler settings file) to
> specify the various options to the different tools. This is a plain
> text file. What I don't like about this approach is that you loose the
> scripting ability. Of course you can write your own programs to
> generate these files. What I fear is that their format might change in
> future releases (please prove me wrong on this).
>
> What I would like is a *standard documented API* for the scripts. For
> the project assignment mentioned above I would like to have a command
> called something like "set_global_clock_signal $clk". If this command
> returned 0 (or some other predefined value) it has succeeded.
> Otherwise, I could a verbose error message by calling some other
> command (e.g. with the command name and result code as arguments).
>
> It would have been even better if the vendor would proved different
> scripting interfaces like TCL, Guile, Scheme, Perl, etc. to their
> tools so the users could pick their favorite scripting language. If
> the vendor provided the C API then users or others could generate a
> shell (they could provide TCL as a minimum or example) for their
> favorite language.
>
> Just my 2&#4294967295;.
>
> Petter
> 1) CSF (compiler settings files) would of course solve this issue.
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

Based on feedback from our UNIX (Solaris, Linux and HP) users, we have
intentionally made our UNIX installs simple and script based. UNIX
environments can be diverse and a script based approach allows power users
to step in and fix things as needed to let them do their job, rather than
wait on factory support for trivial items. A script based approach has also
proven to be very robust and has virtually eliminated all support calls for
installation issues.

Also based on feedback from our UNIX users we have invested substantial
resources in improving our command line interfaces and procedural (Tcl
based) scripting capabilities in Quartus II 3.0 and in the upcoming
releases. More on this in a future post. As usual we welcome your feedback
and in helping make Quartus a better product for you.

- Subroto Datta
Altera Corp.

"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message
news:87smljd8i6.fsf@zener.home.gustad.com...
> uselinux2000@yahoo.com (linux user) writes:
>
>
> >    Altera has very talented engineers, and there is no doubt in my
> > mind that very soon a nice install, possibly similar to the one of
> > Open Office (GUI based) will be available for Linux.
>
> I've been a Linux user since 1993 and I'm very happy to see that Linux
> support from the major FPGA vendors is improving.
>
> However, I would like Altera and Xilinx to spend their efforts on other
> things than a GUI based install program. I recall all the problems I
> have had over the years with the Xilinx GUI based install program
> under Solaris. It would sit there for days flashing cute ads without
> installing anything :-( A simple tar would done the job. Of course you
> most likely need a way of specifying which devices and parts to
> install, but that's about it. Sometimes I install Linux software on
> file servers which don't even have X11.
>
> I would rather have better scripting capabilities, support for
> distributed processing (e.g. synthesis and place and route using a
> cluster to improve throughput), device programming support under
> Linux, Opteron 64-bit support, etc.
>
>
> > 4) Suse 9.0: did anyone try?
>
> I have tried on a SuSe 8 AMD64 system. Quartus II 3.0SP1 bails out
> with the message:
>
> Unknown Linux processor
> MWARCH: Undefined variable.
>
> But I think it should be possible to get it to run by hacking the
> scripts so that it will find its dynamic libraries, etc.
>
> Petter
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?