Posts like this make me happy I didn't get that "dream" job from Altera back in the day and got pulled into software. Closed tools, expensive proprietary equipment to get started, hostage to large vendors. I dodged a career bullet.
The Lack of Open Tooling for FPGAs
71–80 of 125 posts
Re: The Lack of Open Tooling for FPGAs
#72This does a good job of capturing the first part of the problem. Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. The critical thing to understand, is that FPGA users (the big ones, not the casual ones) don't want them to be open. They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass prod…
> Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. Could you provide further details?
http://www.xilinx.com/support/documentation/data_sheets/3000... is the data sheet. I used to have the programming and layout specs doc they gave out.
Re: The Lack of Open Tooling for FPGAs
#73Earlier quoted context omitted.
I am sorry you suffer from the dongle collection woes too. The only reason I can see to buy expensive dongles are the ones that have a big blob of RAM on them for quickly reading debug output from the chip without slowing it down, and ones that can adapt to highly exotic voltages and pin outs automatically. But usually the software for these only work in windows, have secret drivers, and are NOT worth 2 thousand doll…
In the microcontroller world, expensive debug dongles are essentially hardware keys for the software included. Lauterbach's[1] Trace32 for instance don't even have software keys, the license for their very extensive debugging software is stored in the dongle itself. Another piece of software that isn't often mentioned in these discussions is the driver for the embedded flash memory inside parts. USB has quite poor la…
Very well written.
I had no idea some companies went so far as directly making their debugger the software key. That is intense but makes a lot of sense.
In the case of the Xilinx Platform Cable I wrote firmware to, they have a CPLD that does the JTAG writing of data, and a Cypress FX2LP handling the USB information. They use a quad buffered USB endpoint to let the PC load as much crap as possible into USB and in my experience the buffer fills up fast and the jtag work takes the time. Of course this is only because multiple 'pages' were preloaded, otherwise the delay to request more pages would be insane.
Are you talking about the flash driver for loading external SPI flash? If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip. While looking through OpenOCD I found they had drivers for the actual flash, and I am not sure if this is required for the fpga flash boot strapper I just described.
I will look over these links. I recently started messing with ARM chips and they are programmed very differently than FPGAs so I have some stuff to learn on that.
Re: The Lack of Open Tooling for FPGAs
#74Earlier quoted context omitted.
Do you have an offering that would allow me to code up a SystemVerilog->Verilog translation script on a hobbyist budget? I'm stuck coding for my SP605 in Verilog (or VHDL) but I would really like to be able to use structs and interfaces from SystemVerilog. Coming from software dev it's insane: The $500 devkit doesn't support structs and I would have to pay $1300 to get one that does. Meanwhile C has had structs for 4…
I've had similar needs but couldn't find an existing tool, nor a parser on which to build. There are some open source parsers [0], but they don't seem to do preprocessing and hence lose a lot of context. So I made a parser that might work for your use-case given some work: https://github.com/svstuff/systemverilog It works for some fairly big codebases, so I know it's not completely broken. I'm not very proud of the s…
Thanks, looks promising! My needs are pretty minimal at the moment but it will be both refreshing and educational to give this a go.
Duplicating all the DRAM wires at each and every level of abstraction was just hideous.
Re: The Lack of Open Tooling for FPGAs
#75Posts like this make me happy I didn't get that "dream" job from Altera back in the day and got pulled into software. Closed tools, expensive proprietary equipment to get started, hostage to large vendors. I dodged a career bullet.
Those jobs also pay you to sell your ideas that you are never allowed to use again unless you continue working for the company you sold it to. And if you have the gall to use your own idea, lawyers!
Re: The Lack of Open Tooling for FPGAs
#76I'll offer a guess as to why the FPGA manufacturers are hostile to open tools. Open tools reveal the internal details of their FPGA hardware which is their bread and butter. I think it is probably the wrong approach, but that sort of thinking is common around intellectual "property."
That's basically the same reasoning used by most GPU manufacturers, but two of the biggest players in that market have chosen not to act that way and don't seem to be suffering at all for it.
Companies seem to be terrified of trying anything. That is why I was happy when Sony put The Interview up on the internet and theaters for simultaneous release. No one would try that first, and since it worked ok for them it is now an option other companies may consider.
Even though both GPU companies and FPGA companies are in hardware, they do not see strategic experiments like opening documentation in the other to be sign of viability for themselves.
Re: The Lack of Open Tooling for FPGAs
#77Earlier quoted context omitted.
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…
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.…
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).
Re: The Lack of Open Tooling for FPGAs
#78Is is actually a good idea to reverse engineer the internal structure of FPGAs since the manufacturers likely won't disclose their proprietary knowledge ever? The question is, do we really need FPGAs? What about emulating FPGAs in GPUs? Or using massive parallel chips like Parallela or GreenArrays GA-144 (Forth) to simulate logic gates? Such architectures are usually much more open than FPGAs.
I can't see how you could possibly create an FPGA from a GPU, whereas you could/can create a GPU from an FPGA, for example Altera have OpenCL running on FPGAs, and also people have implemented GPUs using an FPGA.
Note that Altera's compiler for Open CL does not let you run your OpenCl stuff faster. It is intended so you can write your FPGA programs (that run outside of your computer usually) in OpenCL. Most of the imagined benefits kind of vanish, at least to me, when you realize that this is just a tool so if all you can hire if OpenCL developers, you can still get the job done.
Re: The Lack of Open Tooling for FPGAs
#79Earlier quoted context omitted.
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.…
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 an…
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.
Re: The Lack of Open Tooling for FPGAs
#80Posts like this make me happy I didn't get that "dream" job from Altera back in the day and got pulled into software. Closed tools, expensive proprietary equipment to get started, hostage to large vendors. I dodged a career bullet.
Those jobs also pay you to sell your ideas that you are never allowed to use again unless you continue working for the company you sold it to. And if you have the gall to use your own idea, lawyers!
Wow. The beatings just continue. I was headed straight into the worse engineering subfield for starting a company, economically as well as legally.