Xilinx ISE drops support for more parts

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>

On Tue, 01 Jul 2003 05:47:25 -0700, 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.
> 
> 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.

If you are going to continue to use parts long after they are obsolete
then you should archive the tools that you used to do the original design.
It's hardly realistic to expect todays tools to support parts that have
been obsolete for 10 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.

On Fri, 04 Jul 2003 08:48:04 +0200, 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.
> 
> Thomas

You complaint is with Synopsys not Xilinx, the Xilinx tools don't have any
hardware enforced licensing. 

On Thu, 03 Jul 2003 09:23:08 -0700, lecroy wrote:


>> I'm not saying that you should or shouldn't use the Spartan chips.  But
>> I am curious as to why you would use such an old technology.  Certainly
>> there are cheaper, faster, bigger chips available.
>> 
> In our case, the designs are done. In are market we are not that
> sensitive to part costs.  The real cost is qualifying a new design just
> to phase out a part the is still being sold.  New designs, no problem.

In extremely long product life markets you have to warehouse everything.
Any board that is old enough to have a 3000 on it is full of components
that haven't been manufactured for years. Chances are you have parts that
were made by companies that aren't even in business anymore. The only way
that you can continue to make those boards is to have stockpiles of parts.
If you are stockpiling parts then you can stockpile software and a couple
of old computers to run it on. Keeping and a couple of old Sparc 1s or 386
PCs in the corner is far cheaper then stockpiling components.

One more thing, you said the reason for continuing to build outdated
systems is the cost of qualifying a new design. Well the same goes for
tools, you don't want to have to qualify a new tool set on the old parts
just so you can do a bug fix. You know that the old tools worked, you
don't know what bugs would pop up in the new tools if you tried to use
them for a really outdated part. 

On Thu, 03 Jul 2003 22:10:58 +0000, Uwe Bonnes wrote:

>
> 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 is right about this. I can say from personal experience that Wine will
run all of the versions of the Xilinx tools going back to the 3.x
releases. Chances are that it will handle earlier releases also, it can
probably even support the XACT tools which ran on Windows 3.1 as I
remember. You could also use Win4Lin which runs any Win9x on top of Linux.
Version 2.x was contemporary with Win95 so you certainly could use
Win95/98 on Win4Lin to run them.

rickman <spamgoeshere4@yahoo.com> writes:

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

http://www.sysinternals.com/ntw2k/source/misc.shtml#VolumeId

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.

> In extremely long product life markets you have to warehouse everything.
> Any board that is old enough to have a 3000 on it is full of components
> that haven't been manufactured for years. Chances are you have parts that
> were made by companies that aren't even in business anymore. The only way
> that you can continue to make those boards is to have stockpiles of parts.
> If you are stockpiling parts then you can stockpile software and a couple
> of old computers to run it on. Keeping and a couple of old Sparc 1s or 386
> PCs in the corner is far cheaper then stockpiling components.

Actually, we are able to still procure all of the components for that
board. All of the companies are still in business.  I'm not even sure
why you are making these remarks as you don't work for us.  Again, we
do end up keeping old PCs around and our older copies of the software
if they were used to create a design.  I would need to do this even if
our friends at Xilinx stopped dropping support for parts every few
years.
 
> One more thing, you said the reason for continuing to build outdated
> systems is the cost of qualifying a new design. Well the same goes for
> tools, you don't want to have to qualify a new tool set on the old parts
> just so you can do a bug fix. You know that the old tools worked, you
> don't know what bugs would pop up in the new tools if you tried to use
> them for a really outdated part.

I have to qualify each new tool as they become available. You are
right, it takes a lot of time which prevents me from releasing every
new update for our own internal use.  If the Xilinx did not remove
support for devices as the tools advance I would qualify them for
older designs. Again, to allow us to leverage a standard user
interface, etc.

On Tue, 08 Jul 2003 12:55:42 -0700, lecroy wrote:

>> I made this statement because one of my clients is in a marketplace
>> (military and medical) where they ship systems for years and years
>> because the customers don't care about the costs they just don't want
>> to rewrite or requalify software.
> 
> That's your client, not us.
> 
>> You don't seem to understand that Xilinx isn't removing support for the
>> old devices, they aren't adding support for those devices to new tools.
> 
> ISE is not a new tool, just a new release with no support for Spartan.

ISE is just the GUI front end for the tools, it's not the important part
of the Xilinx tool suite. The key elements are the mapper (map), the place
and router (par), and the timing analyzer (trce). Xilinx is also now doing
a synthesis tool of their own (XST) which is one more piece of the puzzle
that has to be supported for each device. I was told by Xilinx that map
was rewritten for the 5.x release. The 6.x release is going to be 64 bit
as well as supporting native Linux, so that means that every important
piece of the tool chain is subject to major changes. Which means in turn
that the tool set has to be QAed on every part that it supports. The more
parts that they have to support the harder the QA job is.

>> Periodically Xilinx completely rewrites some component. They do this
>> because the requirements change for each new generation.
> 
> Are you talking for Xilinx now?  Are they also a client of yours?

I'm not talking for Xilinx, but I do talk to them all the time. With any
complex piece of software, not just Xilinx's, you have to make choices
when you go forward that requires you to lose some features that you had
in the past in order to improve support for the things that you need to do
in the future. To give you an example from a field completely unrelated to
this one, last week Adobe announced a new version of their video editing
software, Premiere. As of this release they are no longer supporting Macs,
just XP. Premiere was originally written for the Mac and for years was a
Mac only product but now the number of Mac users is to small for Adobe to
bother doing a Mac port. When they did a radical rewrite they choose that
moment to drop Mac support. The same thing goes for Xilinx and Spartans.
No one is doing new designs with the original Spartan family, so it's not
worth Xilinx spending any money putting in support for Spartans in their
new tool sets. The old tools are completely adequate for doing anything
that you need to do with a Spartan. Just because there is a new better
faster tool set available doesn't mean that the old stuff has suddenly
vanished from the face of the earth. Disk space is cheap, you can have as
many versions of the tools as you want on a system, all you have to do to
switch between one rev and another is change an environment variable.



>> part. If you were to add support for old parts into the new tools you
>> would expect that the new tools to be riddled with bugs for that part
>> for the simple reason that nobody is using that tool set on that part,
>> and therefore nobody is finding the bugs.
> 
> I expect Xilinx to maintain a certain level of quality in their
> software, and I would not expect the tools to be riddled with bugs,
> ever!

All software has bugs and x.0 software has lots of bugs. Xilinx is
actually better than most but whenever they add a new family or do a major
rewrite there are bugs. I did an Altera Stratix design last year and every
piece of software in their design chain was broken, starting with the
Verilog models which wouldn't even compile. I've never had that level of
problems with Xilinx but I've certainly encountered my share of bugs in
their stuff over the years.

> 
>> Anyone who uses a brand new part
>> knows how buggy the tools can be for the first six months or so. Now
>> imagine that you are the only person in the world that was using that
>> part, the bugs would never get fixed.
> 
> And the part would never be made.

My point is that the support for an old part in a new tool wouldn't be any
better than the initial beta release of a new part. The difference being
is that with a new part lots of people are using it so that the software
bugs get found and fixed. With the obsolete part there will be hardly
anyone using it so the bugs aren't going to get found, the fixes aren't
going to get made, and the software quality will be beta forever. With the
tool set that existed at the end of the parts mainstream life the software
was mature. You benefit from the years of cumulative bug fixes that had been
applied, that's the stuff you want to be using if you have to make a
change to an old part.
 
> Again, I have not seen the case you are describing with Altera's router.
> Try to be more data driven with your comments.

As I said before my experience with Altera has been much worse then with
Xilinx. The kind of bugs that I encountered with the Altera tool set
indicated that they hadn't done any QA at all. In all fairness I was doing
a Stratix design which was a beta part at the time so you would expect all
sorts of problems. 

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