6 ms·

The major issue with FPGAs today is that there is no free toolchain for compiling the bitstreams that run on them. The only project I know of to make any real

The major issue with FPGAs today is that there is no free toolchain for compiling the bitstreams that run on them. The only project I know of to make any real progress on fixing this is fpgatools. [0] It supports a single model of the Xilinx Spartan-6 series, the XC6SLX9. I know almost nothing about FPGAs, but seeing as how almost no one is working on this problem, I figured I'd try to add support for the XC6SLX45, the model that is the Novena motherboard. So far I've added the C code to represent all of the pins. [1] Unfortunately, I haven't heard anything from the maintainer about how to proceed further. fpgatools is only a single piece of the puzzle, though. It provides libraries to build the low-level bitstreams, but we'd still need Verilog/VHDL implementations that use it, as well as replacements for the proprietary "soft cores" that most people are using. The amount of work required is intimidating. Not having an HDL readily available did motivate me to have some fun rewriting the example C programs in Scheme, though. [2] Does anyone know about other such efforts to free FPGAs? I'd be very grateful to hear about them. [0] https://github.com/Wolfgang-Spraul/fpgatools https://github.com/Wolfgang-Spraul/fpgatools [1] https://github.com/Wolfgang-Spraul/fpgatools/pull/8 https://github.com/Wolfgang-Spraul/fpgatools/pull/8 [2] https://gitorious.org/davexunit/guile-fpga https://gitorious.org/davexunit/guile-fpga

sklogic 12y ago
Wow! How did I managed not to know of this project?!?
- davexunit 12y ago
  Want to help with the XC6SLX45? :)
  - sklogic 12y ago
    Maybe. I've got an Atlys board (but I'm not sure I'm ready to brick it yet). Currently I'm more interested in trying to use it with the existing open source place&route tools ( https://code.google.com/p/vtr-verilog-to-routing/ https://code.google.com/p/vtr-verilog-to-routing/ ).
- fit2rule 12y ago
  Maybe you also don't know about this project? http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/ They had some interesting progress lately: http://hackaday.com/2015/03/29/reverse-engineering-lattices-ice40-fpga-bitstream/ http://hackaday.com/2015/03/29/reverse-engineering-lattices-...
  - sklogic 12y ago
    Yep, did not hear of this one too. I'm more interested in the Xilinx chips at the moment, but may take a look at the Lattice stuff later.
cgag 12y ago
My roommate is working on this problem: http://diamondman.github.io/Adapt/ http://diamondman.github.io/Adapt/ https://github.com/diamondman/Adapt https://github.com/diamondman/Adapt I don't understand this stuff well, I'll try to get him to comment here.
alain94040 12y ago
I disagree strongly. The major issue with FPGAs today is that they cost money (because they are chips). They cost even more than your CPU. So you can't treat them life software. To put it in simpler words: everyone has access to a CPU, less than 1% have access to an FPGA. Fix that* and the tooling will follow. * one way to make FPGAs "free" is to incorporate some FPGA blocks in an Intel CPU. Then it will feel free.
- davexunit 12y ago
  Intel CPUs are anything but free. They contain nonfree microcode and other nastiness, so they would be unsuitable for free hardware projects.
  - pogden 12y ago
    I think the grandparent is referring to 'free as in beer.' It doesn't cost anything to tinker with programming because almost everyone already has a computer they use for other things. Not so with FPGAs.
- femto 12y ago
  It's the programming model, not the FPGA itself that people are asking to be free (as in freedom, not cost). Comparing to the world of software: the FPGA is analogous to the CPU, the programming model is analogous to the instruction set, the tool chain is analogous to the compiler and the hardware Description Language" is analogous to source code. The freedoms that apply to software/compiler/information can equally be applied to their analogue in the FPGA space. Incidentally, FPGAs start at US$1.24 in single unit quantities from Digikey, and go up from there. US$6.75 will buy a "proper" logic cell based FPGA. They are no more expensive than a CPU. A Zynq development board, which has 2 x ARM cores with integrated FPGA, can be had for US$119 [1]. https://adapteva.myshopify.com/collections/featured-products/products/parallella-16-micro-server https://adapteva.myshopify.com/collections/featured-products... --- Edit: fixed price on dev. board
diamondman 12y ago
PART 1/3 The lack of open tools is a huge problem. My friends on IRC are working on reverse engineering multiple chips enough that full compilation tool chains can work. My part of the project is working to make a highly generic method of loading the compiled files onto the actual chips no matter the programmer or chip used. I will expand on the steps of compiling for an FPGA, loading a program onto an FPGA, the difficulties we face in making our own tools, and then talk about my project a little (which cgag was kind enough to name drop). As you can see from the post size this will be very long but should be very educational. First thing is there are more parts to the bitstream generation, as well as other tools of the toolchain required after bitstream generation is done. The compilation is split into the following parts. HDL SYNTHESIS HDLs can work for both ASIC design, FPGA design, and more general work like some mathematical proofs that never intend to run on real hardware. This step takes in a HDL program and calculates all the gates required. The output is called a netlist is more of a mathematical construct of connections over perfect wires (everything is ideal i.e. not realistic). This step should also detect repeated gate mpatterns in the netlist and de-duplicate them (This is crazy important since it can shrink a netlist substantially). Commonly tools that implement this step will produce everything in one gate type (like NAND http://en.wikipedia.org/wiki/NAND_logic http://en.wikipedia.org/wiki/NAND_logic). There are two major open source tools: Icarus Verilog (http://iverilog.icarus.com/ http://iverilog.icarus.com/) used more for the math proofs and simulation but not intended to generate information for real chips. Yosys (https://github.com/cliffordwolf/yosys https://github.com/cliffordwolf/yosys) A much newer tool that is made to be part of a real life FPGA toolchain once the next tools are available. Only works with Verilog (more popular in industry). TECHNOLOGY MAPPING The link OP posted shows how the FPGA has specialty hardware peppered in with the general gates to speed up certain operations. The link briefly talks about the truth tables in the LUTs which means that each LUT is not really just A gate, they are each a box that can be configured to implement one of many common sequences of gates to save space and speed. Each FPGA can be implemented differently, and since the synthesis step outputs a netlist usually in a specific gate type, the gates of the netlist often do not match the gates that can be efficiently implemented in the LUTs. This tool is the first one that has to have deep knowledge of the FPGA's underlying technology (often called the Fabric) so we can convert the netlist into something that could in theory be put on the target FPGA. Synthesis tools do not implement this step since it is FPGA specific. PLACE AND ROUTE After we generate a netlist of realistic gates we have to find out how to fit them into them onto the physical chip with enough room to connect to each other. This by itself is a VERY hard problem and takes most of the time of the full compilation. It is made more difficult by the fact that this requires extremely specific information about the FPGA's fabric to know not only what paths are available, but also make sure that the paths between LUTs are not too slow so we can send signals around the chip fast enough (programs for FPGAs are not like programs for CPUs where each instruction happens one after the other. In an FPGA all the gates are running at the same time so we have to time the electricity running at the speed of light to give the circuits time to execute, and move LUT's around if our timing is not met. This timing happens in a CPU too, but the CPU designer got this working so our instructions run in a predictable way). BITSTREAM GENERATION The final step of the compilation toolchain is to take the LUT configuration and routing information from place-and-route and convert it to a binary file the FPGA can actually 'run'. Like Place-and-route this step is highly FPGA dependent. We already know the configuration of the fpga we want from the last step so this step is just converting that configuration into the binary file format for the FPGA. This format is also kept secret.
sitkack 12y ago
Just implement an FPGA in Verilog, then use that FPGA as your target. It has the added bonus of making your bitstream portable across Altera, Xilinx, Lattice, etc. One could use genetic algorithm to map the search space so that the virtual fpga compiles cleanly using available resources of the hardware.
- sklogic 12y ago
  I did it (while playing with reconfigurable dataflow CPUs), and timings (expectably) were awful.
  - sitkack 12y ago
    It could see cases where there is an impedance mismatch between the guest FPGA running on the host FPGA. The idea of the genetic algorithm to map out the search space is to find some identity function HDL that allows for a clean 1:1 or 2:1 mapping of resources without incurring some combinatorial inefficiency. Maybe c-slowing could help with the timings, even if the area used was 4x it would still be a great research platform for reconfigurable computing since the bitstreams are proprietary, not documented and not portable. http://blog.notdot.net/2012/10/Build-your-own-FPGA http://blog.notdot.net/2012/10/Build-your-own-FPGA

sklogic 12y ago

Wow! How did I managed not to know of this project?!?

davexunit 12y ago
Want to help with the XC6SLX45? :)
- sklogic 12y ago
  Maybe. I've got an Atlys board (but I'm not sure I'm ready to brick it yet). Currently I'm more interested in trying to use it with the existing open source place&route tools ( https://code.google.com/p/vtr-verilog-to-routing/ https://code.google.com/p/vtr-verilog-to-routing/ ).
fit2rule 12y ago
Maybe you also don't know about this project? http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/ They had some interesting progress lately: http://hackaday.com/2015/03/29/reverse-engineering-lattices-ice40-fpga-bitstream/ http://hackaday.com/2015/03/29/reverse-engineering-lattices-...
- sklogic 12y ago
  Yep, did not hear of this one too. I'm more interested in the Xilinx chips at the moment, but may take a look at the Lattice stuff later.

cgag 12y ago

My roommate is working on this problem: http://diamondman.github.io/Adapt/ http://diamondman.github.io/Adapt/ https://github.com/diamondman/Adapt https://github.com/diamondman/Adapt I don't understand this stuff well, I'll try to get him to comment here.

alain94040 12y ago

I disagree strongly. The major issue with FPGAs today is that they cost money (because they are chips). They cost even more than your CPU. So you can't treat them life software. To put it in simpler words: everyone has access to a CPU, less than 1% have access to an FPGA. Fix that* and the tooling will follow. * one way to make FPGAs "free" is to incorporate some FPGA blocks in an Intel CPU. Then it will feel free.

davexunit 12y ago
Intel CPUs are anything but free. They contain nonfree microcode and other nastiness, so they would be unsuitable for free hardware projects.
- pogden 12y ago
  I think the grandparent is referring to 'free as in beer.' It doesn't cost anything to tinker with programming because almost everyone already has a computer they use for other things. Not so with FPGAs.
femto 12y ago
It's the programming model, not the FPGA itself that people are asking to be free (as in freedom, not cost). Comparing to the world of software: the FPGA is analogous to the CPU, the programming model is analogous to the instruction set, the tool chain is analogous to the compiler and the hardware Description Language" is analogous to source code. The freedoms that apply to software/compiler/information can equally be applied to their analogue in the FPGA space. Incidentally, FPGAs start at US$1.24 in single unit quantities from Digikey, and go up from there. US$6.75 will buy a "proper" logic cell based FPGA. They are no more expensive than a CPU. A Zynq development board, which has 2 x ARM cores with integrated FPGA, can be had for US$119 [1]. https://adapteva.myshopify.com/collections/featured-products/products/parallella-16-micro-server https://adapteva.myshopify.com/collections/featured-products... --- Edit: fixed price on dev. board

diamondman 12y ago

PART 1/3 The lack of open tools is a huge problem. My friends on IRC are working on reverse engineering multiple chips enough that full compilation tool chains can work. My part of the project is working to make a highly generic method of loading the compiled files onto the actual chips no matter the programmer or chip used. I will expand on the steps of compiling for an FPGA, loading a program onto an FPGA, the difficulties we face in making our own tools, and then talk about my project a little (which cgag was kind enough to name drop). As you can see from the post size this will be very long but should be very educational. First thing is there are more parts to the bitstream generation, as well as other tools of the toolchain required after bitstream generation is done. The compilation is split into the following parts. HDL SYNTHESIS HDLs can work for both ASIC design, FPGA design, and more general work like some mathematical proofs that never intend to run on real hardware. This step takes in a HDL program and calculates all the gates required. The output is called a netlist is more of a mathematical construct of connections over perfect wires (everything is ideal i.e. not realistic). This step should also detect repeated gate mpatterns in the netlist and de-duplicate them (This is crazy important since it can shrink a netlist substantially). Commonly tools that implement this step will produce everything in one gate type (like NAND http://en.wikipedia.org/wiki/NAND_logic http://en.wikipedia.org/wiki/NAND_logic). There are two major open source tools: Icarus Verilog (http://iverilog.icarus.com/ http://iverilog.icarus.com/) used more for the math proofs and simulation but not intended to generate information for real chips. Yosys (https://github.com/cliffordwolf/yosys https://github.com/cliffordwolf/yosys) A much newer tool that is made to be part of a real life FPGA toolchain once the next tools are available. Only works with Verilog (more popular in industry). TECHNOLOGY MAPPING The link OP posted shows how the FPGA has specialty hardware peppered in with the general gates to speed up certain operations. The link briefly talks about the truth tables in the LUTs which means that each LUT is not really just A gate, they are each a box that can be configured to implement one of many common sequences of gates to save space and speed. Each FPGA can be implemented differently, and since the synthesis step outputs a netlist usually in a specific gate type, the gates of the netlist often do not match the gates that can be efficiently implemented in the LUTs. This tool is the first one that has to have deep knowledge of the FPGA's underlying technology (often called the Fabric) so we can convert the netlist into something that could in theory be put on the target FPGA. Synthesis tools do not implement this step since it is FPGA specific. PLACE AND ROUTE After we generate a netlist of realistic gates we have to find out how to fit them into them onto the physical chip with enough room to connect to each other. This by itself is a VERY hard problem and takes most of the time of the full compilation. It is made more difficult by the fact that this requires extremely specific information about the FPGA's fabric to know not only what paths are available, but also make sure that the paths between LUTs are not too slow so we can send signals around the chip fast enough (programs for FPGAs are not like programs for CPUs where each instruction happens one after the other. In an FPGA all the gates are running at the same time so we have to time the electricity running at the speed of light to give the circuits time to execute, and move LUT's around if our timing is not met. This timing happens in a CPU too, but the CPU designer got this working so our instructions run in a predictable way). BITSTREAM GENERATION The final step of the compilation toolchain is to take the LUT configuration and routing information from place-and-route and convert it to a binary file the FPGA can actually 'run'. Like Place-and-route this step is highly FPGA dependent. We already know the configuration of the fpga we want from the last step so this step is just converting that configuration into the binary file format for the FPGA. This format is also kept secret.

sitkack 12y ago

Just implement an FPGA in Verilog, then use that FPGA as your target. It has the added bonus of making your bitstream portable across Altera, Xilinx, Lattice, etc. One could use genetic algorithm to map the search space so that the virtual fpga compiles cleanly using available resources of the hardware.

sklogic 12y ago
I did it (while playing with reconfigurable dataflow CPUs), and timings (expectably) were awful.
- sitkack 12y ago
  It could see cases where there is an impedance mismatch between the guest FPGA running on the host FPGA. The idea of the genetic algorithm to map out the search space is to find some identity function HDL that allows for a clean 1:1 or 2:1 mapping of resources without incurring some combinatorial inefficiency. Maybe c-slowing could help with the timings, even if the area used was 4x it would still be a great research platform for reconfigurable computing since the bitstreams are proprietary, not documented and not portable. http://blog.notdot.net/2012/10/Build-your-own-FPGA http://blog.notdot.net/2012/10/Build-your-own-FPGA