Hacker News new | ask | show | jobs
by bravo22 4077 days ago
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.

2 comments

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.

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.

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