I've been poking Xilinx through various techniques about this. I talked to three or four people Xilinx about it at the recent Embedded Systems Conference in San Jose; I also tried to talk to Steve Long(? might be misremembering his name) who apparently is a software manager, but I kept missing him. I also asked the support guy who has been handling the bugs I file to pass an email up the chain, and he said he did. Perhaps it'll land with someone who is willing to take me up on an offer to talk about it more.
If everyone with a complaint about the quality of the software does this, perhaps Xilinx would realize that there are people out there (such as myself) who think FPGAs are incredibly cool and are willing to work on the software without expectation of payment as long as certain open-source rules are observed. The single best example of this is Michael Gernoth in the thread entitled "Xilinx Platform cable USB and impact on linux without windrvr"[1]. He was willing to work on it despite the lack of source, and his result is /quite/ impressive.
I think the main problem is some level of confusion. Open-sourcing XST and the various GUI apps does not mean that map/par need to be fully open-source. Providing map and par as libraries that user-written apps could call would be perfectly acceptable, given the level of trade- secrecy involved. Xilinx is not a software company, and it shows. They should be leveraging the software to increase adoption of the hardware, not limiting industry growth with low software quality. Once the realization of this percolates up, perhaps we'll see some changes.
So, once again. If you have a complaint about the quality, make a reasoned argument to whoever at Xilinx will listen. Remember that zealotry and insults won't work here; there is a strong business case for this to happen, but it requires such a shift from traditional thinking that every overzealous attempt will cancel out quite a few reasonable ones. Perhaps one who is a better wordsmith and evangelist than I can come up with a template that others can use.
We are reading these posts. We are taking note of suggestions. Some of them are intriguing, others are not workable.
We also appreciate the posts without the venom, and without the 'agendas.'
Many on this board are consultants, who make their money by filling in the spaces that Xilinx has missed, ignored, or not done very well in. More power to them, and thank you for being part of the Xilinx eco-system. Also, thank you for pointing out where Xilinx can improve.
Some of these folks add no value, and are struggling to survive. We have to read between the lines.
I'm probably the one you were looking for at ESC. I am not an expert on open source software, but will give you my thoughts on why it won't work for FPGAs: - We have a fair amount of 3rd party software that we ship with ours and we have no rights to distribute that source. - We have about 250 people writing software. While I'm sure there are
20 or 30 people that think FPGAs are cool enough to want to help out, I doubt there are enough. - Most of our time is spent doing new device support (and this in not just within the map and par groups). How do we get these "volunteers" to deliver new devices when we need them? - We start the software for new devices about 2 years before the software for that family is released. Making the details of a new architecture public at that time is not an option. - Going open source is like handing our source code over to our competitors. - I'm not exactly clear on who would support our customers as they run into bugs, but I guess it would be us meaning we would have to have people ready to fix someone else's code. - The only other open source program for FPGAs failed:
formatting link
There are some applications, like the schematic editor, that I would be willing to consider going to open source if someone could show me how that would benefit us and our customers.
Regarless of the negative comments we receive on this newsgroup, most customer comments on ISE 9.1i have been extremely positive. Plus, we have put a number of quality initiatives in place and you should see the results of that over the next year.
For what it is worth, my experience so far with ISE9.1 has been good, which was a pleasant surprise after my transitions to previous major releases. For the most part, my stuff (almost all pushing the envelope) has turned in pretty much the same timing as it got with 7.1sp4 but in a fraction of the run time, and most importantly without choking on my extensive use of RPMs and RLOCs. I can't point at any examples where timing got worse under 9.1, but on the other hand, I also can't point at any where timing got noticibly better either.
The only choke points to date have been ucf issues (mostly things with differential pins that are unused in the design but called out in the UCF with iostandard set). Certainly nothing that isn't easy to work around.
First, the suggestion is not to fully open source, but to be more 'open source friendly' in portions of the systems.
Mike said this "Open-sourcing XST and the various GUI apps does not mean that map/par need to be fully open-source. Providing map and par as libraries that user-written apps could call would be perfectly acceptable, given the level of trade- secrecy involved."
A good example of an opposite [user unfriendly] trend is the binary Project file. What was Xilinx thinking ? [I think that's now resolved ?]
You'll see from the postings that the "work around" is alive and well in FPGA development, and is is IMPORTANT to not close any "work around" pathways'.
Programming has been mentioned as one area that benefits.
snipped-for-privacy@xil> Mike,
Yes, but these are back-end issues, not front end ones. See Antti's post about how he had to patch the ISE design flow, in order to get a build. That's not a P&R bug, but shell/test coverage issue.
Yes, I'm not sure what ST were trying to do ? An end-end open source is plainly not going to fly, on anything like leading edge FPGA designs.
As run-times get faster, and incremental flows are better supported, it opens more tool-chain options to users.
eg All Xilinx needs to do is define the reports well, and define the project files, tool chain scripts, seeds, and batch operations so users can control (and fix) things.
None of that is releasing trade secrets, but it allows developers to push areas Xilinx cannot afford to.
The same thing was said about Netscape, and now Mozilla/Firefox is a big Open Source success story. The 3rd party software is gone, along with the licensing fees.
There certainly aren't enough to replace your in-house team. That is not realistic. But I think you are missing one of the biggest benefits of Open Source. It is not just about writing software. It is also about helping your customers use and understand your software. There have been many times I have run into some cryptic error message, or a program that aborts for some unknown reason. If it is an Open Source package, I can grep the source for the error message, or pop it into a debugger to see why it is aborting. But if it is closed source, I often have to resort to hours or days of random fiddling with the input till I get past the problem.
Most companies have "strategic" software that contains valuable IP, and encapsulate the core competencies that make that company successful. Then they have lots of "non-strategic" software that sucks up resources, but provides little or no competitive advantage.
Open Sourcing your PAR software would be reckless. But Open Sourcing GUI code or device drivers may make sense.
This is a known problem with a known solution. You have a "stable track", that you support, and a "development track" that is only supported by the OSS community. You only move code from the dev track to the stable track when you have reviewed the code and decided that it is good quality and has worthwhile new features. Most big Open Source projects work this way.
This failed for some obvious reasons. A company can't just "stone soup" an Open Source project without putting something into the pot. It also wasn't really open. If it was, then ST wouldn't be able to just cancel it unilaterally.
Well, I think the schematic editor would be a poor choice for testing the waters. I know no one that uses it. The customers who do use it are probably those most uncomfortable doing programming, and so would be the least qualified to contribute or benefit.
I think a better choice would be to open source iMPACT. I doubt if it contains any strategic IP. There are six computers in the office suite where I work, including Win-XP, Linux, and FreeBSD on x86_64; and Win-XP and Linux on x86_32. ISE runs fine on all of them. iMPACT runs on precisely one (Win-XP on x86_32). It fails on all the others for various reasons. It also fails to work on VMware. These sorts of driver and OS compatibility issues are something the OSS community is quite good at fixing.
My experience with ISE 9.1i has been almost entirely positive. It is a solid improvement over 8.2. But don't get too defensive about the negative comments. Positive comments are worth little. It is the negative feedback that helps us improve and progress. If no one ever complained, we would still be living in caves.
That's a v.good idea for a starting point. I'd also like to see ChipScope follow that. Even if it's just the UI, not the core. (Of course, if the core did go open source, I'd be happy to add a clock enable for the core's clock input, and make the thing usable at >200MHz, but that's a separate gripe...) Cheers, Syms.
It failed for ONE SIMPLE REASON: IT WAS NEVER STARTED OR OPENED. The project was cancelled before ANY open-source development on the project started.
So please dont say the open-source project failed - because there was none. Would it have been started, chances are it would not have failed.
Antti
LATEST Xilinx BUG: Unable to register TclNotifier window class
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. make: *** [microblaze_i/lib/libxil.a] Error 3
Done!
PRE-LATEST XILINX BUG SAME as latest but error number 66
the next one, in EDK project "can not process edkbmm file" (this was a formerly working project pre 9.1)
the next one, this time in ISE: Main Menu-> "Open Project" - NOTHING Happens! no dialog nothing.
EVERY school boy can make a "File Open" dialog to appear at least. Xilinx has trouble even with this task.
I know there are plenty of customers who are happy with ISE 9.1SP3 but there are also those who arent. And not all of them give feadback. So the existance of happy customers should not be treated as definitive indicator that the software is good at all.
Antti who is starting another fight to force Xilinx latest and greatest software to perform the simplest tasks.
eh, agreed the "hard things" that really matter are probabley way better in ISE 9.1SP3
just a pity that "some small things" make trouble, besides I did not comment so much on ISE 9.1, but the 9.x "complete" most of the issues are related to EDK not ISE.
and here too if running all tools from commandline there are good chances that everything works fine.
my latest issues - well I got a urgent project (demo needed monday) and in the attempt to use some ISE+EDK combined desing from pre 9.1, well I got maybe 6 different errors not related to the design. It is still not passsing the full flow.
Tell me about it. I'm using 8.2. I don't normally like to change versions during a project, but I think I'm going to do so now. I've seen malicious viruses be more user friendly than this. But, I mustn't be venomous, after all I only need to use this stuff so I can earn a living. Cheers, Syms.
I tried 8 after a few service packs, and could not get existing designs through it, so I stuck with 7.2sp4 until recently (beginning of April). 7.2sp4 was far more usable than any version of 8. That's why I was pleasantly surprised when my stuff ran through 9.1sp3 without a hitch. I too do not like changing tools mid-project unless there is a compelling reason. I also do not move up a major revision until at least the second service pack and after seeing how others have fared with it. I've spent far too many unreimbursed hours debugging major releases in the past so I avoid it like the plague.
OpenOffice.org is another great example of this system; the project is maintained entirely in the open, by a community made up of both Sun employees and outsiders. When it becomes time for a new release of StarOffice (Sun's branded version of OpenOffice.org) Sun takes the current snapshot, adds in the functionality they cannot release as open-source, and releases it. If a company wants a support contract, they need to use StarOffice, but OpenOffice is acceptable to everyone else.
I really couldn't have stated my case better than this. If most of your man hours are spent doing new device support, who is fixing bugs? Who is testing? No offense intended, but it seems like the answer is "not enough people." (How does a bug like CR 437985 slip through?) If you had outside help fixing bugs, more of your internal time could be devoted to adding device support. In the case of the cable drivers, you should read this[note 1] link. If you contact Greg KH ( snipped-for-privacy@suse.de), a member of the Linux Kernel team, I believe you would be pleasantly surprised.
This is true. However- what would they do with it? (Note that we are talking about pieces that are not trade secrets here, since I am not arguing that you should compromise your hardware IP.) If you open- sourced the ISE and EDK (and the eclipse packages for the SDK), Altera could then take them, improve them, and release them, this is true. However, this would help you both. If you release under the GPL[note
2], Altera would be held by the same rules- any improvements they made and released would have to be open-source as well. If there was one free GUI tool that supported both Altera and Xilinx, I can't see this as being anything but a win for Xilinx. As I see it, Xilinx has the edge in hardware design, and Altera has the edge in software design. If you improve your software by opening it up while maintaining the edge in hardware, /and/ make it easier to switch from Altera to Xilinx by removing the need to learn new software, that is a clear win!
In addition, open-source hardware projects don't tend to do particularly well (though I'm hoping the video card/ GPU project will succeed) but that's definitely not what we're talking about here.
I'm going to be a little harsher than Bob here. What you're seeing is a clear example of selection bias.
Many customers are already your customers, and you have been making slow but steady improvements in the software. ISE 9 is certainly a vast improvement over the dark ages of ISE 6 and 7. Kudos are due for that, certainly. If you ask regular customers what they think of recent versions of your software, of course they will be positive. Do you have statistics on the number of people who considered FPGAs for a project and decided not to? Do you have numbers on small webpack-only projects that jumped ship due to the software quality? How about internal R&D projects that have failed due to Xilinx bugs? I have experience with that last one myself- we're probably going to be going with an outside micro coupled with a small FPGA rather than using an FX-series chip w/ PPC due to the sheer number of problems I've had with it. And I know what I'm doing!
Your customers are primarily hardware companies, so any improvement is gravy to them. They judge your software against others in the EE domain, and find it usable. However, I'm not comparing your software to software in the domain, I'm comparing it to software in other industries. Why do I do that? The FPGA market doesn't /have/ to be this way- there doesn't have to be a hazing ritual for every new user. I have a dream where a software-only engineer [namely, most of my friends] could simply buy a dev kit and have something nifty working within an hour or two of it arriving in the mail. Much like the way Lego Mindstorms work- Lego is brilliant with usability. If you design your software so a 10-year-old could use it, you're pretty much covered all your bases :)
Most people are probably going to laugh at the preceding paragraph. But I'm completely serious. Why do I feel so strongly about this? A lot of people in the FPGA industry seem to think the status quo is just fine. But not me. I want FPGAs to become ubiquitous. I want my PC to have an FPGA /instead/ of a processor. And I don't see that happening unless it becomes easier for software people to become FPGA people. Right now, most software people I know flee back to a microprocessor when they see the state of the FPGA industry. And that makes me sad.
1)
formatting link
2) There are many frightening things said about the GPL, most of which are not true. If you've heard some of those things, let me know and I will attempt to address them in a future mail.
Steve said that the majority of >200 developers' time is spent on coding up support for new devices and silicon features. He was not suggesting that they are too busy to fix bugs.
There are never enough people testing software! :)
The developers test their modules as they develop new code. They test when they integrate their modules. The software verification group test the software at many levels. The IP developers do a lot of alpha testing since we usually need bleeding edge tools for the latest families. The FAEs test the software. And so on.
Could we do better? Yes, I think so. Do we just ship it as soon as it compiles (as seems to be commonly implied around here)? No, we really don't.
I'm a big fan of open source software and I'd love to see more OSS projects surrounding FPGA technology. But I'm not quite sure about the feasibility of what's being suggested in this thread.
First of all, what exactly is the scope of this "open source ISE" supposed to be? If it's just a vendor-agnostic IDE for designing FPGAs, then it sounds like a trivial wrapper around the proprietary synthesis and back-end tool flows. Most serious FPGA developers already have their own makefiles and associated infrastructure that eases the portability of their design from one vendor's device to another's. At which point, slapping a sparkly GUI on top of it is not a high priority for them.
Now taking it up a level, an open-source implementation of something like EDK (~SOPC builder) would be interesting. The idea of FPGA design as the convenient stitching together of prefab building blocks, either from a standard library or custom-made for the current project, has a lot of mileage in it. And it's an ideal way to factor out vendor dependencies.
An open-source equivalent of the Core Generator (~MegaWizard) could work; all these things help to hide the low-level implementation details and focus on the system level. A free and open-source solution for managing libraries of parameterizable IP would really help people to create portable designs while still making efficient use of the target architecture. (I'm not talking about people instantiating shift registers and counters here, but higher-level processing blocks.)
But would it make sense to try and do an open source FPGA floor-planning tool? I don't think so. The level of dependence on the device internals is prohibitive. For the same reason, mapping, packing, placement and routing algorithms look destined to remain proprietary, at least for the time being. OSS versions would lag a vendor-proprietary system significantly because vendors just won't release early details of their new architectures to the general public. They need to retain a competitive advantage or they will go out of business. I cannot see that changing; at least not until there is one single company's architecture dominating the FPGA landscape (a la Intel in the late 1990s).
There are obvious parallels here with the software world and general-purpose processors, but there are differences too. The EDA back-end is significantly more complex than (say) the GCC back-end, because the FPGA feature set - as exposed to the "programmer" - is considerably more complicated too. It's tempting to argue that because GCC was possible, that an open-source vendor-independent HDL-to-gates compiler is possible too. But this is proof by analogy.
My conclusion is that the only parts of the FPGA toolchain that vendors will likely be willing to open-source are the bits that the open-source community would not be interested in anyway. A notable exception is the JTAG programming stuff, as has been pointed out by several others. I would be incredibly happy to see a proper, flexible, standard stack for accessing JTAG devices - and to achieve that, I think an open source effort is pretty much the *only* approach that will work.
This advert irritated me. It's message seems to be that because _some_ people made _some_ bad predictions, it must be that _all_ predictions are wrong, therefore Linux will be a success because _some_ people say it will fail. That logic is bollocks. ;-) There are plenty of reasons why, IMHO, open source is a 'good thing', but that ad didn't present them. Cheers, Syms.
In my NVIDIA GPU, I had to disable the transparency feature 'cause it caused EDK8x to freeze on the BSB wizard. You can imagine the amount of headache this caused me until I managed to hack my way out utilizing speculative guess!
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.