Xilinx ISE drops support for more parts

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.

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
Reply to
hamish
Loading thread data ...

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.

Reply to
B. Joshua Rosen

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

Reply to
B. Joshua Rosen

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.

Reply to
B. Joshua Rosen

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.

Reply to
B. Joshua Rosen

formatting link

Reply to
Thomas Heller

I think we covered the archive a while back.

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

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.

Reply to
lecroy

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.

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.

Reply to
lecroy

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.

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.

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.

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.

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.

Reply to
B. Joshua Rosen

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

Reply to
rob d

As you may have read in one of my prior posts, we use the Alliance tool set. Preaching about what the tools are is no value to me. We have been using them for years. So this is no value.

I would rather them stay focused on making a better product under MS than remove resources to work on LINUX and possibly add more problems for themselves. Just my preference. I guess all the major tool people are porting their code anyway so we will see. Nothing to do with the original posting, but fun to talk about.

I'm sure most of us do.

If the code were structured, supporting the older devices would not be a problem.

Agree, but again, they drive different and have their own bugs that you need to remember.

No value.

Again, does not help the original problem.

Disagree.

Have used Altera for seven years or so and have had good results.

If they don't address known bugs that would be the case.

No value.

Thanks to Xilinx, this is the way you have to operate. So again, your not saying anything of value.

I would have to say my experience has been a wash between the two.

Sounds like some of the problems I find with Xilinx. Even you yourself just posted about all the bugs you seem to find in the Xilinx tools. It's bad when they know the bugs are there and don't have the resources to address them on a major release.

Reply to
lecroy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.