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.
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.
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 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.
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.
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.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...