I'm still reading above the level I currently understand when talking about FPGAs and chips and such… but how does Bunnie's Novena[1] factor in to all this?
[1] https://en.wikipedia.org/wiki/Novena_(computing_platform)
The Lack of Open Tooling for FPGAs
121–125 of 125 posts
Re: The Lack of Open Tooling for FPGAs
#122Earlier quoted context omitted.
I am OP astrodust: That is exactly the problem :). Turns out ISE (Xilinx's tool) has several command line tools that are run by the GUI in order, but the arguments are not documented. I was able to make a Makefile that did the ISE compilation so I could edit in emacs, but that was way too much crap to be real. The new generation of Xilinx's tools, vivado, is written in Java and does not output any temporary files so…
> a C to fpga compiler which you would suspect could do some crazy things and took thousands of engineering hours to make work. But instead it just implements a CPU in the FPGA Is that seriously how Vivado HLS works? Now I'm glad I decided not to buy it.
How well HLS does highly depends on the source code (this is in general and not specific to Vivado HLS). If your code is a simple loop over an array and you add a vendor-specific #pragma directive (such as #pragma unroll) the tool will unroll your loop and extract the parallelism from there. This actually works quite well in practice for regular DSP code (like FIR and FFT) and floating point. Anything else is another story though.
The thing is that unless you're writing your code as the tool expects it, with the proper pragmas etc. there's no way it can be transformed to fast hardware. A way around that is for vendors to ship "customizable IP" kind of like Altera's Megafunctions... so much for portability and high-level.
I'm not sure which tool OP is referring to though, I remember Altera had a C2H tool that they discontinued in favor of their OpenCL SDK.
Re: The Lack of Open Tooling for FPGAs
#123Earlier quoted context omitted.
> So how does having a closed tool chain achieve that? It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though…
Some people have been preventing cloning by locking their bitstream to the FPGA's unique serial number, which exists partly to allow people to do this. This is trivial to work around if you know the bitstream and device internals.
I disagree that it is trivial. If we know what bits of the unencrypted bitstream do what, and have a cryptographically secure way of signing the stream, then GLHF with that. If it turns out that documenting the parts of the chip required for configuration makes the black box security not work, then it was crap security and provided no real security to anyone. As it stands there is no way to tell and we have to take the smiling sales guy's word that it is "SUPER secure, promise".
Re: The Lack of Open Tooling for FPGAs
#124I have done a lot of GPU programming, and interested in looking into FPGA for low power solutions. Will this situation improve with the release of OpenCL support?
OpenCL support for FPGAs is super limited and only done through vendor specific tools. The point of these tools is more to LET you write your FPGA program that runs outside of a desktop computer in OpenCL than it is to make an FPGA be able to speed up your OpenCL program running on a desktop. So it is not like 'I will pop in a new FPGA card so I can play better games.' Though that is what i want to happen in the next…
You're confusing OpenCL with high level synthesis (HLS). OpenCL is explicitly a platform for software developers. It targets accelerator boards attached to a host (via PCIE), just like GPGPU.
https://www.altera.com/solutions/partners/opencl-board-partn...
Re: The Lack of Open Tooling for FPGAs
#125An interesting talk on "How to Build an Open Source FPGA toolchain" was presented at the Open Hardware Workshop a few years back: http://www.ohwr.org/attachments/821/sebastien.pdf