[diamondman]

I am OP

You are correct some of the information required to build a computer for these chips are 'internal' details. However they already have strict patents on most of it, and knowing the configuration bits of a chip and the the delay of various paths is not going to give away their fabrication technique. They could potentially release just enough details to satisfy compiler writers instead of making us do it ourselves so we try to rip every details out of it.

[goodcanadian]

You are not wrong, and I think the first company to support open tools would gain a competitive advantage . . . I know I would give them my business.

They could release some details, but they won't. They perceive it to not be in their interest. They are probably wrong about that, but that is the way they perceive it.

[bravo22]

Often times there are clever optimizations and work around that have to be implemented to work around internal limitations that they don't publish so as not to give their competitor marketing advantages.

What we should be pushing for are cross platform tool. Being open-source isn't something that I necessarily would care about as an EE in this particular case. It doesn't get me anything I don't with vendor tools. The BIGGEST thing in FPGA/ASIC design is certainty. Error in the tool costs me time and money.

You'll find it difficult to convince anyone to a tool that isn't supported by the vendor because errors and bugs, in the tool or the tool data, won't get resolved quickly.

Most of the money in ASIC/FPGA is spent on "verification" either as pre-build/pre-tested cores or as tools that do verification, such as formal logic tools.

[diamondman]

Hmm, that is a way I did not think about. Documenting hardware limitations for compilers gives competitors leverage for saying theirs is better because it does not suffer from X.

I understand that open source is not particularly important to you, but I am a bit more skeptical about the verifiability of a product that is all secret sauce and promises than I am about something with open check-able code and test suites. Open source software very rarely tries to hide its flaws to prevent a PR issue and then lazily fixed in the future because it is 'low priority', instead they are fixed by whoever can, verified, etc. There are always counter examples, but I thing the verifiability of the tool is in the same world and of similar importance to the verifiability of the output.

You do make a point in the catastrophic cost of a screw up when casting an ASIC though.

[bravo22]

FPGA/ASIC interchangeable for the purpose of verification. There are two types of verification: A) does the post synthesis gate match my RTL B) Does my RTL do what I want it to do, i.e. matches the spec.

For B you have a whole host of third party IP, verification library, assertions, etc. that you can use

For A there are formal verification tools. They mathematically match A to B. There is no need for that tool or anything in the chain to be open.

Synthesis is complex and an optimized synthesis is very important. Timing closure is where a lot of this stuff comes to the forefront and that's the part that vendors won't release. That's their secret of what sucks in their chip, or what workarounds they have to use. You'll pry it from their dead cold hands.

As an engineer I don't care about their secret. I care about making sure that I don't have to chase down a synthesis bug and that their compiler gives me the most optimized, fast design. Synplify used to be a third party product that did FPGA synthesis (Synopsys bought them). They discontinued it, even though though they had full specs/details from Xilinx/Altera. The main reason is Xilinx/Altera tools are excellent. They know their chips better than anyone and for marketing purposes it is in their interests to give you the tool that does the fastest design, or smallest design. Otherwise you would switch to their competitor.

I love the idea of what OP is trying to do but it is a solution in search of a problem.

There is a bigger problem that an open source tool could solve and that is Verilog simulation. Currently we have Icarus Verilog but someone should improve it and add SystemVerilog support. Simulation is much easier to solve, since there is a spec to design against, and has many more users. There aren't good, inexpensive simulation tools. Simulation is as important as compilers. Imagine a world where gcc didn't exist and you had to pay to get a good compiler.

People will always stick to the big vendor for synthesis. I can't imagine a day that they wouldn't.

[makomk]

One nasty little caveat is that Xilinx's tools will not synthesize certain elements, such as state machines, in the way you've written them for performance reasons. Caught me out - I was trying to use an open source design someone else had created with Synplify, and it used a Grey-code state machine to cross between two clock domains. Xilinx's synthesis tool replaced it with a one-hot state machine which was not safe for this purpose and worked for a while then randomly wedged itself. To be fair, the synthesis log did mention this in amongst the huge pile of other messages.

[diamondman]

OP here

You are right that my particular project is not the biggest piece, but it is the part that pisses me off. I can deal with Xilinx's crappy compiler if I can program my chips with ease..... or maybe I should say UNTIL I can program my chips with ease. Then my focus will change hehe.

Icarus works but it has been maintained by one 'eccentric' guy for quite a while and the code base is semi unapproachable. I believe this is why the Yosys guys started from scratch.

You are also right that the place and route, as well as verification of the LAYOUT in the chip are super big problems. It is in fact what my friends toying with the compiler side are dreading dealing with because we have no idea the delays of individual traces in the chip.

I disagree that people will stick with the vendors tools. Open compilers dominate most of the Intel CPU market besides on windows since Visual Studio is the only thing that deals with all the quirks reasonably well. But the windows case is more of a lack of interest.

ARM compilers are more interesting to me because most people use Keil. Keil... works. But it feels crazy retro paying for a compiler. I believe the only reason that Keil is being used for most embedded ARM projects is there simply are not enough people with compiler knowledge using ARM regularly yet to pour enough work to make a better alternative.

But it will come.

And one day we will have synthesis tools for FPGAs that are comparable to the big guys or better.

[bravo22]

I fully support the spirit of what you're doing btw. I hope you don't take my comments as somehow dumping on your work ;).

What is "crappy" about Xilinx tools aside from the UI? I'm genuinely curious.

I don't think the comparison between synthesis tools and compilers hold. They are different beasts. I think compiler equivalent is sim tools which should be open and free.

Everyone that I've talked to who uses Keil uses it because of SUPPORT. If they need something or there is a bug they know it'll get fixed. That's the ONLY reason anyone has EVER cited to me. It is not true that lack of alternatives is due to lack of knowledge. There just isn't a big enough market for it. ARM itself also makes all the patches for GCC tools. I use gcc toolchain as do many people.

[diamondman]

Haha, not at all. I do not take it as an attack or anything :).

The UI is obvious. The inability to use most of the intermediate file formats for anything since they are secret formats is annoying. If I remember correctly it had dependencies on Java and Mono. The command line tools are archaic and very difficult to use even before realizing they are not documented out of the fear of giving something away about how anything works. The iMPACT for programming chips incorrectly loads the libusb.so file and has to be LD_PRELOADed on linux, but even then there is some weird race condition that makes it work 1 out of 4 times. In order to do anything you have to download and install 15 gigs of data and agree to aggressive licenses.

The compiler tool chain usually is a compiler and a linker. I could understand if you said that the place and route was more of a linker step, but people often call the full process 'compilation'. The fact that stitching the modules together and actualizing the equivalent of addresses and instructions (in CPU terms) is a physical fitting and box packing problem in an FPGA does not make it a fundamentally disparate step to me.

Wow, I did not know that about the ARM compilers. I must have got the wrong impression from forum posts on the use of GCC for ARM chips. That makes me pretty happy, particularly that ARM is helping with the open tools. I will say though that this feels like it is supporting my point because people are using the non vendor tools. If support is a concern, support is not something that only a big company can provide. Postgres provides support and adds features on auction. I will admit that the responsiveness of Oracle for their customers having a need is much bigger and more organized, but it better be for what people pay for that. With the Oracle example, I think I am leaning towards 'there will always be room for a proprietary solution to handle edge cases of a market' instead of open solutions will not work as well as proprietary ones and are unable to be the defacto standard.

[coryrc]

Xilinx iMPACT (the FPGA programmer) bugs:

On one version, it can load the project it saved, but then crashes when you go to program. So you have to scan and reload all the data files every time you start it.

Later version, failed to program the chip at the last stage of the process. Diagnosed that over phone tag where the user was non-technical and on a machine not connected to the Internet. Exact same chip as above.

Another later version has different iMPACT bugs than that first version above, but right now I haven't been able to get it to work on any Win 8.1 machine so I don't remember which bugs it has.