Xilinx ISE drops support for more parts

[lecroy]

I am reposting after a memo from reader siting problems using the
Xilinx link to post to this group. Sorry about any problems this may
have caused.

After the release of Alliance 3 support was no longer offered
for the XC3xxx family. Worse, if you did not happen to
have the original software that supported these
devices, Xilinx would not sell you a copy. Even today we
still have product that uses the 3xxx family.

I am looking at upgrading our group to Allience 5.x
and again see that Xilinx has dropped all support for
Spartan. Other families were dropped as well. We would
now need three copies of software running to
support the Xilinx devices we use. Of course, not all
the Xilinx tools like to be co-installed, so it's multiple
computers or swap installs.

Xilinx, what is your problem? Altera may drop parts, but
their router continues to support all of their devices.
Is your software so poorly written that it is so difficult
to maintain parts that you need to drop them? I could understand
if the parts were no longer available, or you at least sold
older copies of your software.

 

[Steve Lass]

lecroy wrote:

I am reposting after a memo from reader siting problems using the
Xilinx link to post to this group. Sorry about any problems this may
have caused.

After the release of Alliance 3 support was no longer offered
for the XC3xxx family. Worse, if you did not happen to
have the original software that supported these
devices, Xilinx would not sell you a copy. Even today we
still have product that uses the 3xxx family.

If you're having trouble getting software for 3K devices, let me know.

I am looking at upgrading our group to Allience 5.x
and again see that Xilinx has dropped all support for
Spartan. Other families were dropped as well. We would
now need three copies of software running to
support the Xilinx devices we use. Of course, not all
the Xilinx tools like to be co-installed, so it's multiple
computers or swap installs.

Xilinx, what is your problem? Altera may drop parts, but
their router continues to support all of their devices.
Is your software so poorly written that it is so difficult
to maintain parts that you need to drop them?

The issue is not the software, it's the testing. With thousands of

device/package/speed
grade combinations, plus the platforms and OSs, plus all the EDA
interfaces we support,
there are millions of possibilities that need to be tested. Since the
Spartan software was
high quality, and we didn't want to destabalize it with enhancements
needed for newer
architectures, we decided to freeze the Spartan software. This allows
us to focus our
testing efforts where they are needed most.

Spartan software is available for free at:
http://www.xilinx.com/ise_classics/index.html

By the way, I don't expect us to be dropping any more architectures from
our FPGA
tools.

Steve

I could understand
if the parts were no longer available, or you at least sold
older copies of your software.

 

[Philip Freidin]

On 1 Jul 2003 05:47:25 -0700, lecroy7200@chek.com (lecroy) wrote:

I am reposting after a memo from reader siting problems using the
Xilinx link to post to this group. Sorry about any problems this may
have caused.

Thanks, I appreciate the lack of HTML in the news group.

After the release of Alliance 3 support was no longer offered
for the XC3xxx family. Worse, if you did not happen to
have the original software that supported these
devices, Xilinx would not sell you a copy. Even today we
still have product that uses the 3xxx family.

At least for XC4000E, EX, XL, XLA, and Spartan, the SW is
available as Xilinx "Classic" software (free, but need normal
xilinx user id/password).

http://www.xilinx.com/webpack/classics/spartan_4k/index.htm

I am looking at upgrading our group to Allience 5.x
and again see that Xilinx has dropped all support for
Spartan. Other families were dropped as well. We would
now need three copies of software running to
support the Xilinx devices we use. Of course, not all
the Xilinx tools like to be co-installed, so it's multiple
computers or swap installs.

As for maintaining multiple versions of the software
on the same computer, I have found that VMWARE (www.vmware.com)
is a very good solution. I basically set up a virtual computer
for each version of the software, and each is kept separate
and there are no conflicts. Costs a few GBytes of disk, which
these days is only a few $.



Philip Freidin



Philip Freidin
Fliptronics

 

[Peter Alfke]

Too many German quotes.
Uwe's was
"It is easier for a camel to go through the eye of a needle, than for a
rich man
to enter into the kingdom of God"
New Testament, St. Matthew 19:24

Maybe you remember from Sunday School...
Peter A
======================
Uwe Bonnes wrote:

To cite the Bible:

"Eher geht ein Kamel durch's Nadeloehr, als dass ..."

 

[Uwe Bonnes]

Marius Vollmer <mvo@zagadka.de> wrote:
: Peter Alfke <peter@xilinx.com> writes:

:> Old software is available for free, but may require an old computer
:> OS.

: What about releasing the source of unsupported tools into the public
: domain, or as Free Software? Unmaintained binary only software is not
: a big help, but old source code that one can maintain oneself is a
: winner.

: You might also learn a thing or two about the 'Free Software / Open
: Source community' that way and how it might help you make Xilinx more
: popular.

To cite the Bible:

"Eher geht ein Kamel durch's Nadeloehr, als dass ..."

Probably the software is hopelessly interweaved with externally licensed
software and other parts that are still considered crucial. I doubt that
there is a big difference between an FPGA suite and Netscape. And look what
effort it took to get from Netscape to Mozilla. The audience for a FPGA
suite is orders of magnitude smaller.

Anyways, such a move would be great...

Bye

B.t.w.: For maintaining legacy version of windows software, the windows
emulator wine (www.winehq.com) might be an option for the
not-so-faint-hearted.

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

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

 

[Thomas Heller]

Steve Lass <lass@xilinx.com> writes:

Jim Granville wrote:

Can we get a quick summary of what's removed, and what legacy
versions of SW are needed to support which family ?

The current software (version 5.1i, 5.2i, 6.1i) supports Virtex,
Virtex-E, Virtex-II, Virtex-II Pro, Spartan II, Spartan IIE, and
Spartan-3.
ISE Classics (version 4.2i) supports XC4000E, XC4000L, XC4000EX,
XC4000XL, XC4000XLA, Spartan, and SpartanXL.

Contact the hotline if you need software for:
3.1i supporting XC3000A, XC3000L and XC5200.
XACT 6 supporting XC2000, XC3000, and XC4000, XC4000A and XC5200.

This sounds like I better terminate my Xilinx software subscription, and
use the free versions instead.

I recently changed my PC to a new one, and tried to install the licensed
version of ISE 4.2, because I need Spartan and Spartan XL. It was a
pain to make it work again because one design uses FPGA express, and it
always complained about the license being invalid.

The only solution was, as a Xilinx FAE told me, to use use tool to
change the volume serial number of my hard disk to the one that the old
PC had. Fortunately I didn' have to reregister Windows XP again.

Thomas

 

[rickman]

Thomas Heller wrote:

Steve Lass <lass@xilinx.com> writes:

Jim Granville wrote:

Can we get a quick summary of what's removed, and what legacy
versions of SW are needed to support which family ?

The current software (version 5.1i, 5.2i, 6.1i) supports Virtex,
Virtex-E, Virtex-II, Virtex-II Pro, Spartan II, Spartan IIE, and
Spartan-3.
ISE Classics (version 4.2i) supports XC4000E, XC4000L, XC4000EX,
XC4000XL, XC4000XLA, Spartan, and SpartanXL.

Contact the hotline if you need software for:
3.1i supporting XC3000A, XC3000L and XC5200.
XACT 6 supporting XC2000, XC3000, and XC4000, XC4000A and XC5200.

This sounds like I better terminate my Xilinx software subscription, and
use the free versions instead.

I recently changed my PC to a new one, and tried to install the licensed
version of ISE 4.2, because I need Spartan and Spartan XL. It was a
pain to make it work again because one design uses FPGA express, and it
always complained about the license being invalid.

The only solution was, as a Xilinx FAE told me, to use use tool to
change the volume serial number of my hard disk to the one that the old
PC had. Fortunately I didn' have to reregister Windows XP again.

Which tool did you find that would let you change the disk serial
number?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

Rainer Buchty <buchty@atbode100.informatik.tu-muenchen.de> wrote:

In article <3f042929$0$23100$5a62ac22@freenews.iinet.net.au>,
hamish@cloud.net.au writes:
|> I don't think dropping support for old devices is too unreasonable.
|> Otherwise the QA effort for each new software version (major, minor,
|> even service pack) just grows bigger and bigger, and the design of
|> the software gets more complex and messier etc.

Why would this be so? If the software is modularized, e.g. the fitter
(placer/router) is its very own piece of command-line software there is
no need to touch that code again (plus, doing so eases portability).

But can you be sure that it's completely standalone and won't need any
QA? Have you changed any of the toolchain used to build the tools
themselves? There's lots of things that could go wrong, requiring QA,
which is expensive.

If integration of the necessary calls into the GUI is an issue, well, then
just leave it out. From what I read in this and other "tech" groups,
developers seem to prefer to write their own batch scripts anyway. (If
the shared development machines sit "two networks further", you don't
want to wait for GUI updates anyway.)

But the same people who can write those scripts can make multiple ISE
versions co-exist; it's trivial. I suspect it's the GUI users
complaining about old tools being dropped.

Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

 

[rob d]

lecroy7200@chek.com (lecroy) wrote in message news:<9297c711.0307071137.4a64f1fd@posting.google.com>...

I think we covered the archive a while back.

It's hardly realistic to expect todays tools to support parts that have
been obsolete for 10 years.

Again, we are talking Spartan which has not been obsolete for ten
years.

Periodically some major component of the tools
gets completely rewritten, when that happens it's hard enough for them to
put in support for all of the current parts let alone add support for all
of the old parts.

Altera just keeps adding more support for their older devices to
Quartus. It's their newest tool. Maybe they have more time on their
hands.

For the record, many years ago when Altera launched their very first
stab at an FPGA a MAX5128 design suddenly stopped fitting. Almost all
of Altera's revenue was from Max5x and Max7x at the time but their QA
had let the fitter algorithms change for the FPGA while breaking it
for Max5x.

I am much more comfortable with Xilinx's attitude, but I expect that
guys designing with rad hardened 4's (spartan) wish it were otherwise.

Rob

 

[lecroy]

The issue is not the software, it's the testing. With thousands of
device/package/speed
grade combinations, plus the platforms and OSs, plus all the EDA
interfaces we support,
there are millions of possibilities that need to be tested. Since the
Spartan software was
high quality, and we didn't want to destabalize it with enhancements
needed for newer
architectures, we decided to freeze the Spartan software. This allows
us to focus our
testing efforts where they are needed most.

I am a bit surprised that with software this complex that there was no
way to de-couple the various parts. I am sure Xilinx does a lot of
testing on their software, but I am always amazed when I find a bug
that is known about and it takes them several major releases to fix
it. My favorite was VHP__0854 The expression can not be converted to
type std_logic_vector. That bug was there forever and finally fixed in
4.x.

We currently hold 7 Xilinx licenses that cost us about $10K a year to
maintain. With Xilinx claiming to be best in class I expect more.

I find it interesting when I had called the Xilinx hotline that they
said there was no way to get the older software. It's not an issue
for us as we maintain them. For others this may be a problem.

The bigger problem is that we have some parts that we use that
requires us to keep an old Window 95 PC setup just to support the old
software. Plus, we don't get to leverage the newer interfaces as they
are developed. Instead we are forced to remember how to use the old
tools. This costs us time and money.

Thanks for picking up Synplicity. We use their full tools. Fast,
don't drop support, and best of all, their tools work.

 

[lecroy]

As for maintaining multiple versions of the software
on the same computer, I have found that VMWARE (www.vmware.com)
is a very good solution. I basically set up a virtual computer
for each version of the software, and each is kept separate
and there are no conflicts. Costs a few GBytes of disk, which
these days is only a few $.

Good advice, but it addresses they symptom, not the root problem. I
don't want to have to work around what Xilinx is doing. I want them
to do a better job for us.

 

[lecroy]

JoeG <no@where.net> wrote in message news:<3F0219B6.8F56CB33@where.net>...

I've ask Xilinx the ? about legacy support for years -- I have the same
problem with XC4005 series -- we have hundreds fielded on MILITARY
applications. However Xilinx newer tool suites Foundation/Alliance DO NOT
support these legacy devices. So we are STUCK with maintaining an OLD
machine with OLD Xilinx XACT software.

I feel for you, and every other company who is now in this trap thank
to Xilinx. I think with Xilinx dropping Spartan, you really have to
wonder what their long term plans are. Will we have one "stable"
version of software for each series? Each version with it's own
interface, bugs and PC requirements? Is this really what we expect
from a company who claims to be the best?

I had called Xilinx marketing to ask some of these questions, and like
the person I spoke to on the Hotline, they just don't have a clue what
the long term plans are. Who is driving the ship?

 

[rickman]

lecroy wrote:

JoeG <no@where.net> wrote in message news:<3F0219B6.8F56CB33@where.net>...
I've ask Xilinx the ? about legacy support for years -- I have the same
problem with XC4005 series -- we have hundreds fielded on MILITARY
applications. However Xilinx newer tool suites Foundation/Alliance DO NOT
support these legacy devices. So we are STUCK with maintaining an OLD
machine with OLD Xilinx XACT software.

I feel for you, and every other company who is now in this trap thank
to Xilinx. I think with Xilinx dropping Spartan, you really have to
wonder what their long term plans are. Will we have one "stable"
version of software for each series? Each version with it's own
interface, bugs and PC requirements? Is this really what we expect
from a company who claims to be the best?

I had called Xilinx marketing to ask some of these questions, and like
the person I spoke to on the Hotline, they just don't have a clue what
the long term plans are. Who is driving the ship?

It is real simple. The FPGA marketplace is mainly between two players.
So a maker can focus on a few aspects of the product to compete well in
the marketplace. I don't expect that long term support in the tools is
a major issue with the majority of users at selection time and even if
it is, who else can you choose? Is one really that much better than the
other? My experience with the A vendor had one very bad example of tool
support for an older product. It was still in the tool, but they
wouldn't consider a bug fix even when there was no viable work around.
I don't mean to keep harping on this problem, but it was very signficant
to us and I now realize that there were a lot of ramifications other
than just the technical issue.


--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jim Granville]

Steve Lass wrote:

lecroy wrote:
snip
I had called Xilinx marketing to ask some of these questions, and like
the person I spoke to on the Hotline, they just don't have a clue what
the long term plans are. Who is driving the ship?

I'm driving the ship and like I said, we have no plans to drop any other
architectures from our
software. All the FPGAs we have in the software now are derivatives of
the Virtex arcitecture
so keeping them in the release is not difficult.

Steve Lass
Director, Software Product Marketing
Xilinx, Inc.

Can we get a quick summary of what's removed, and what
legacy versions of SW are needed to support which family ?

Peter A mentioned SpartanXL as being still active,
(and lowest power?) but not supported in the latest SW ?

I also noted in another thread that Altera ADDED support for
an older 10Kxx family to Quartus 3.0.

-jg

 

[David R Brooks]

Steve Lass <lass@xilinx.com> wrote:
[snip]
:I'm driving the ship and like I said, we have no plans to drop any other
:architectures from our
:software. All the FPGAs we have in the software now are derivatives of
:the Virtex arcitecture
:so keeping them in the release is not difficult.

My apologies if I've missed something: I join this thread late.
But now I'm worried: I was about to start a new design using Spartan:
exactly what has been dropped? (It wasn't evident from the Xilinx
website).

 

lecroy <lecroy7200@chek.com> wrote:

support the Xilinx devices we use. Of course, not all
the Xilinx tools like to be co-installed, so it's multiple
computers or swap installs.

All the tools co-exist from what I've seen. You just need to set your
PATH and XILINX environment variables appropriately for each version.
That probably precludes selecting any version of any tool from the Start
menu, but you can easily write a batch file to choose a version then run
the tool from the command line. (floorplanner, fpga_editor, par, pace,
etc.)

I don't think dropping support for old devices is too unreasonable.
Otherwise the QA effort for each new software version (major, minor,
even service pack) just grows bigger and bigger, and the design of
the software gets more complex and messier etc. We just did something
similar at my work - dropped support for old hardware in a new software
version. The complexity and QA effort was killing us.

At least Xilinx keep all the support notes for the old tool versions on
their web site.


Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

 

[Rainer Buchty]

In article <3f042929$0$23100$5a62ac22@freenews.iinet.net.au>,
hamish@cloud.net.au writes:
|> I don't think dropping support for old devices is too unreasonable.
|> Otherwise the QA effort for each new software version (major, minor,
|> even service pack) just grows bigger and bigger, and the design of
|> the software gets more complex and messier etc.

Why would this be so? If the software is modularized, e.g. the fitter
(placer/router) is its very own piece of command-line software there is
no need to touch that code again (plus, doing so eases portability).

If integration of the necessary calls into the GUI is an issue, well, then
just leave it out. From what I read in this and other "tech" groups,
developers seem to prefer to write their own batch scripts anyway. (If
the shared development machines sit "two networks further", you don't
want to wait for GUI updates anyway.)

Just my $0.02,
Rainer

 

[Steve Lass]

Rainer Buchty wrote:

In article <3f042929$0$23100$5a62ac22@freenews.iinet.net.au>,
hamish@cloud.net.au writes:
|> I don't think dropping support for old devices is too unreasonable.
|> Otherwise the QA effort for each new software version (major, minor,
|> even service pack) just grows bigger and bigger, and the design of
|> the software gets more complex and messier etc.

Why would this be so? If the software is modularized, e.g. the fitter
(placer/router) is its very own piece of command-line software there is
no need to touch that code again (plus, doing so eases portability).

Our software is modular, but each module is not self contained. There

are common routines we
use for constraint parsing, command line handling, IO interfaces,
database management, base
level mappers, etc. Making changes to these common utilities can have
unexpected effects on
older software. This was a bigger issue for us with the pre-Virtex
architectures. Like I said,
since all FPGAs in the software are based on the Virtex architecture,
there is no reason for us
to drop any more families.

Right now, our software is over 20 million lines of code. If each
architecture's software was
self contained, my guess is, that would double. I would think that most
of you would rather we
put our testing effort into the more recent architectures.

Again, the 4K and Spartan/XL software is available, fully supported, and
free.

Steve

If integration of the necessary calls into the GUI is an issue, well, then
just leave it out. From what I read in this and other "tech" groups,
developers seem to prefer to write their own batch scripts anyway. (If
the shared development machines sit "two networks further", you don't
want to wait for GUI updates anyway.)

Just my $0.02,
Rainer

 

[lecroy]

I'm driving the ship and like I said, we have no plans to drop any other
architectures from our
software. All the FPGAs we have in the software now are derivatives of
the Virtex arcitecture
so keeping them in the release is not difficult.

Steve Lass
Director, Software Product Marketing
Xilinx, Inc.

Steve, you have a tough job making these calls, and I am sure you are
guiding Xilinx in a maner that is best suited for them. I believe you
when you made the statement "..we have no plans to drop ...". I am
sure there were no plans to drop any parts from the tools at a given
time.

Fool me once, shame on me. (3.x drops 3xxx parts) Fool me twice (5.x
drops Spartan +), .....

Our company has been using Xilinx exclusively. This latest move from
Xilinx has caused us to re-think our stratagy. All of the tools we
use to interface with Xilinx will support both companies and we mostly
deal with strick VHDL. Supporting both Altera and Xilinx is not a
problem.

Xilinx is sending someone next week to talk with us. Should be
interesting.

 

[Peter Alfke]

Here are some tutorial notes, to calm the waves:

The physical life-length of typical FPGAs is >>10 years continuously at
the max allowed stress. In practical terms this means they work and are
reliable for 50 years or even longer, effectively forever. "Old FPGAs
never die, they just get obsolete".

The commercial availability of popular parts is well beyond 10 years
after introduction. Unpopular sleepers may be discontinued earlier. Any
responsible manufacturer gives you 1 to 2 years of warning and "last
buy" opportunities, and sometimes transfers the die inventory to an
"afterlife" supplier.

Software support in the most current releases can be a problem, and has
been discussed here. For Xilinx, the architectural commonality of all
Virtex and Sparten-II ( and later) devices makes it easier to maintain
support for all these families. Old software is available for free, but
may require an old computer OS.

Design-in life is much shorter, since newer devices make the older
devices appear slow and expensive. "One year in the life of an FPGA
equals 15 years of human life" means that a device introduced 2 years
ago is in its prime, a device introduced 4 years ago is now a senior
citizen, fully capable but not to be raced against the newer parts.
(There are special cases: Spartan-XL, with its roots in XC4000, is
today the last really low idle-power FPGA family, and is 5-V tolerant
and -compatible.)

Freshly announced parts are exciting, but the user must ascertain their
availability. The manufacturer should not be criticized for releasing
product details ahead of availability. That gives the user a chance to
plan and evaluate.

And finally, we all know and understand that the frentic pace of FPGA
innovation is at odds with the long design cycle time of miltary and
aerospace projects.

Just some common thoughts...

Peter Alfke
==========================