3 ms·

You can write the tools you describe on top of any existing tool stack -- you'll just have to use the hardware description language as an IL. (Indeed, many too

by jwise0 13y ago

You can write the tools you describe on top of any existing tool stack -- you'll just have to use the hardware description language as an IL. (Indeed, many tools already do this.) You could write your own synthesis front-end and place-and-route back-end, but they're not like any compilers you've ever seen before. (A recent Coursera class [1] went into pretty good detail about how synthesis and place and route work.) I think that the unfamiliarity is probably why there are no Open Source toolchains for it. For Virtex-II platform, Xilinx provided a tool to edit bitfiles, called JBits [2], but it seems to be well and truly dead[3]. [1] https://www.coursera.org/course/vlsicad https://www.coursera.org/course/vlsicad [2] http://www.xilinx.com/labs/projects/jbits/ http://www.xilinx.com/labs/projects/jbits/ [3] http://forums.xilinx.com/t5/Virtex-Family-FPGAs/Question-about-JBits/td-p/33215 http://forums.xilinx.com/t5/Virtex-Family-FPGAs/Question-abo...

lambda 13y ago
Sure, you could use tools that target the HDL as an IL, if you wanted to write that code yourself and then ship it to your customers as a binary blob, as their HDL compilers need to be specifically licensed, and aren't, as far as I know, something designed to be used as a back-end component in shipping software. But that limits its usefulness for something like, say, writing a GLSL compiler so you can use your FPGA as a GPU, and are then able to run arbitrary GLSL code on it. I agree that it's definitely a much different than writing a compiler backend for a CPU. You are definitely going to have different abstractions that will apply well to it. But that's fine; that's what I'm interested in, writing a compiler for a very different kind of platform. The problem is, as far as I can tell, they don't document their actual bitstream format, so you must use their licensed tools any time you actually want to compile something new for the FPGA. And that precludes a lot of use cases.

by jwise0 13y ago

lambda 13y ago

Sure, you could use tools that target the HDL as an IL, if you wanted to write that code yourself and then ship it to your customers as a binary blob, as their HDL compilers need to be specifically licensed, and aren't, as far as I know, something designed to be used as a back-end component in shipping software. But that limits its usefulness for something like, say, writing a GLSL compiler so you can use your FPGA as a GPU, and are then able to run arbitrary GLSL code on it. I agree that it's definitely a much different than writing a compiler backend for a CPU. You are definitely going to have different abstractions that will apply well to it. But that's fine; that's what I'm interested in, writing a compiler for a very different kind of platform. The problem is, as far as I can tell, they don't document their actual bitstream format, so you must use their licensed tools any time you actually want to compile something new for the FPGA. And that precludes a lot of use cases.