Is the number of users too small? Are we all to busy to answer questions and help out other engineers?
Maybe the tools are too proprietary, and kept under the control of the vendors. Makes no sense really. You would think letting people help each other on the web would be better than paying for support people.
There are a number of problems. Here are several that come to mind (vendor names have been omitted to protect me):
1. Each tool release often behaves (and misbehaves) a little (or a lot) differently from the other releases. So the answer to the question could depend a lot on which release you're using, so even if someone wants to help the answer may not apply to the release used by the questioner.
2. There's one particular set of vendor tools I use that's really inscrutable about how it finds "include" files and other things. I typically only use it for one week per year, so when I get back to it I have to "explore" quite a bit to come back up to speed. I'm terrified that someone will ask me how to use the tool and I'll look like an idiot because I can't even explain to myself how to use it -- "you kind of poke around here and there and hope you get lucky". The tool suite actually has some great things in it, but finding them isn't easy.
OTOH, a different vendor's tools allow me to bypass the GUI and go directly to the command line and use a Make file to re-build a design. This is a very nice option.
3. One pet peeve is the myriad "false-alarm" warnings one gets when synthesizing a design. Hidden within those may be some important warnings, so you can't just ignore the whole lot. I wrote a "sed" script to process the synthesizer report and extract the warnings. This makes it easier to compare to the previous warnings after a design change. This only works for one release of the vendor software -- a different release could very easily make big changes in the warnings.
I suppose I should be glad that FPGA tools are so hard to grok because it makes work for FPGA consultants, but then we have to suffer as well. Plus, clients try to avoid FPGAs because it's hard to find people who can design with them.
There's a very simple solution to all this: FPGA vendors should open up their architectures so that the open source movement can produce more useable tools. Vendors would save a fortune by not having to maintain all that software and they could concentrate on silicon. You don't see ARM and Intel writing their own compilers, and look how they ended up.
I agree, the vender version problem is a mess. Maybe tagging by version. I have found fixes and patches for old versions in mailing list threads that are completely wrong too many times to count.
Documenting the failings of a given version is not popular with the vendors.
The fact you have to poke around to figure out how to use the include files is a reason to have a Q&A site. If there is a question with the ultimate answer, you can just go back to the question and not have to figure it out yourself every time. Plus, maybe it would save someone else from the same pain.
I doubt they will ever open source the tool chains. It only makes sense to protect the income. Even open initiatives like UVM and open cores are not well supported. Intel does make it's own compilers, as does ARM. They cost money, so not many people use them. Because the tools are free, no one wants to pay for anything.
dougwithau wrote: I doubt they will ever open source the tool chains. It only makes sense to protect the income.
I don't want the vendors to open-source their tools. I just want them to document their chip architectures so that people can write and distribute alternative tools.
I didn't realize Intel produced compilers -- I thought the last one was PL/M. Just goes to show how much impact they have. Does ARM write its own compilers or do they just re-sell compilers written by a partner?
I just came across this cool Web-app that makes quick videos of your screen or web-cam or audio-only, and shares them with your target list. It can make video FAQs and video knowledge base articles to drastically reduce trouble ticket volume. There is a free single-user version.
Yes agreed not much information is easily available regarding EDA tools if you need any help. May be there can be more forums and engineers who have hands-on experience using specific tools give their comments with some screenshots. And then like in all forums all similiar topics are together it can be. Experience people can come in together across the world online and contribute.
For most stuff, I don't want a video. For a number of reasons. You can do a screen capture showing where a menu item should be. That and a little text is much more efficient that a video. " hi, this is so and so and I'm here to show you how to add a node to an existing net... bla bla bla". I agree in having stuff available via web. I just don't want to have to fire up a video to do it.
I agree. I'd much prefer a screen capture with a little text to a video. I find the increasing tendency to make everything into videos highly annoying. It's especailly true if you can't be sure which video will answer your question.
I find the secrecy around how to use certain features of EDA programs to be really annoying. It wouldn't be so bad if the help button would bring up something that actually answered my questions. A couple days ago, I was trying to figure out how to package the schematic. I found lots of help on how the packager worked and what the options were but nothing that said what menu to open or what button to click. I finally figured it out by noticing an icon in a dialog box on one of the help screens.
In 2005 ARM boughtKeil, so yes ARM writes there own compilers too.
But as you correctely wrote, the Chip Vendors should openly document there architectures. Else we can't have a competition between tools and tool manufactures as we have in the software world. And competition is good for speed, efficiency (Power and time to market) and usability.
As @ChristophZ says, "In 2005 ARM boughtKeil, so yes ARM writes there own compilers too", and some other silicon manufacturers have made the same.
Maintaining a complete integrated development suite (IDE) is costly and requires a lot of effort. What manufacturers like ARM, Microchip, Freescale, and others are doing is moving most software developing resources to one single part, the compilers toolchain, and let the open software community do the rest. This is accomplishable at present due to the maturity of projects like Eclipse.
Some manufacturers are acquiring the software development companies and others are creating strategic alliances with them.