[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.

[diamondman]

You have to change out a certain DLL for POST windows 8 in order to get ISE to behave and not crash randomly. YAY! Xilinx said they didn't care but somewhere on their support forum there is some kind soul who said what dll to rename (they have two versions of the DLL in the install anyways but they did not use the win 8 one by default and refuse to patch).

[copascetic]

This is entertaining. I've used Xilinx's tools for a while, almost exclusively on Linux (CentOS usually). I thought that renaming/symlinking libraries to get things to work was something only Linux users needed to do, and I figured this was just because Xilinx tests more on Windows (makes sense). If these kinds of problems also affect the Windows versions, then, I don't even know what to say. At some point you just can't make excuses for this stuff anymore.