5 ms·

FPGA: Why So Few Open Source Drivers for Open Hardware?

98 points by caution 6y ago

qppo 6y ago
> The bad part is that most of C/C++-compatible HLS tools are proprietary, and open source ones are either Scala-based (Chisel, SpinalHDL) or seem to be academic toy projects. Why is Scala a problem?
- coreyoconnor 6y ago
  (scala dev here) Scala has a history of embedded domain specific languages that are difficult to understand. (Rather like Perl now that I think about it.) This is not universal in scala EDSLs but definitely exists. So it's a fair concern in general. IMO Chisel is a nice EDSL so, in this context, the concern is unwarranted.
- TD-Linux 6y ago
  I think the article author is mixing up HLS tools and HDLs. HLS tools convert some subset of C to a hardware implementation, and thought that Chisel/SpinalHDL were converting Scala to hardware. But they are really just HDLs implemented as a DSL within Scala, much like Migen uses Python but does not execute Python code on the FPGA.
  - mupuf 6y ago
    Yeah, I definitely jumbled both in the same basket. I should rename that into "higher-level languages" and introduce both HLS and HDL there. Thanks for the feedback, I'll make some changes to clarify my thoughts!
- microcolonel 6y ago
  In addition to Chisel and SpinalHDL, BlueSpec is now open source! [0] Among the available options, I remember people being very happy with BlueSpec even before, and now you don't really have many excuses. [0]: https://github.com/B-Lang-org/bsc https://github.com/B-Lang-org/bsc
  - jakear 6y ago
    Nice! I used it in college and took a liking to it, it was pretty easy to write a full multi core riscV processor with mmu/etc even as my first exposure to hardware design. The compile times were killer though. Has much progress been made there?
Teknoman117 6y ago
> This enables a $37 part (XCA712T) to be able to fit over 3 Linux-worthy RISC-V processors running at 180 MHz, with 720 kB of block RAM available for caches, FIFOs, or anything else. The $100 Alchitry Au has an XC7A35T and 256 MB of DDR3. Currently waiting for them to come back in stock, they're super neat and are open hardware. They're basically the successor to the Mojo V3.
- jack12 6y ago
  > are open hardware. Are they? I only see PDFs of schematics on their website, and no claims of being open. Of course with a breakout board like that there isn't really any secret sauce in the "source", just the expertise, trials and errors, and grunt work of layout. At that same level of "schematics available" dev boards, another option for a XC7A35T and 256MB DDR3 are the ones on aliexpress for $50, https://github.com/ChinaQMTECH/QM_XC7A35T_DDR3 https://github.com/ChinaQMTECH/QM_XC7A35T_DDR3, though I don't think they have the transceiver pins exposed and are bring-your-own-jtag-programmer. All the IO is via 0.1" headers, which are going to be lower integrity but a LOT easier and cheaper to use. There's also a $99 XC7A100T board, https://github.com/ChinaQMTECH/QM_XC7A100T_WUKONG_BOARD https://github.com/ChinaQMTECH/QM_XC7A100T_WUKONG_BOARD, with 256MB DDR3, a gigabit ethernet phy, hdmi port, 0.1" headers and PMOD headers, and with some transceiver pins exposed.
  - rjsw 6y ago
    Why can't people build more dev boards with 32-bit wide DRAM ?
    - _sbrk 6y ago
      Why do you want it, and how much are you willing to pay?
  - mupuf 6y ago
    Thanks for the links. I'll make sure to check them out in details!
rjsw 6y ago
The title suggested to me that they were looking for Linux/BSD drivers for IP within an FPGA, either connected to a CPU using PCIe or for an ARM/FPGA hybrid.
- mshockwave 6y ago
  i agree it's kind of confused. But from a compiler dev perspective (which i think is closer to OP's perspective), driver means a piece of software that put together components / tools and bootstrap the processing pipeline
- imheresamir 6y ago
  Is that not what the author is referring to? From the readme of his LiteDIP project[1]: "Plug-and-play LiteX-based IP blocks enabling the creation of generic Linux drivers. Design your FPGA-based SoC with them and get a (potentially upstream-able) driver for it instantly!" [1]: https://gitlab.freedesktop.org/mupuf/litedip/ https://gitlab.freedesktop.org/mupuf/litedip/
  - rjsw 6y ago
    There isn't anything there apart from the readme. I built a descriptor block into a FPGA design about 15 years ago, this was for PCI so I could put it at a fixed offset into the BAR for every device. I don't see how the "get a (potentially upstream-able) driver for it instantly" would work. Someone would still need to write a driver, you just get a way to probe for whether to attach it or not.
    - mupuf 6y ago
      Sorry about that, the project is still very early. Check out the fan_wip branch for actual code. The point of LiteDIP is to provide both the IPs, and their drivers. Also, rather than needing IPs to be located at a certain address in any sort of bus (PCI BARs, wishbone, ...), litedip exposes the list of IPs starting at address 0 along with their version and relative address. The driver then lists these blocks, and either has a driver for this block's version or not.
throw_Away1337 6y ago
I don't know a lot about this topic but I had an introduction class where we also covered FPGAs. The prof offering the class though is really sufficient in this topic and has developed this tool: https://github.com/esa-tu-darmstadt/tapasco/blob/master/README.md https://github.com/esa-tu-darmstadt/tapasco/blob/master/READ... As you are saying it seems like just a science toy project but he was quite convinced that it already works pretty good and good enough for fourth-semesters to work with it. The tool itself is a high level c++ tool-chain to develop for FPGAs. You should definitely check it out :) Then there's also Bluespec Verilog which has been open sourced not too long ago. It is way more abstract than Verilog or system Verilog and in comparison to them it's a pleasure to write in. But it's definitely not as high-level as C++.
inamberclad 6y ago
Open hardware is relative. Most of these parts still require the xilinx or altera tools. Only the ice40 and ECP5 chips from lattice are really functional with an open source toolchain. I'm quite grateful to lattice for that, even if they had no part in it, they haven't been inhibiting the open source community's efforts.
- mupuf 6y ago
  My understanding was that open hardware stood for "open PCB design", with the idea that a community could be made around it to improve the design for later revisions. Open toolchains are another topic, and indeed, Lattice FPGAs are now super attractive because of it! Hopefully, project X-Ray will bear fruits soon and I can ditch Vivado, at least during development! In the end, a hardware design using Lattice or Xilinx FPGAs is not more or less open. Discrete components will always be proprietary (unless your name is Sam Zeloof). What matters is pushing the boundary further and further, and for this, FPGAs are amazing!
  - abetusk 6y ago
    Open Source Hardware is not limited to just the PCB design. Here is an excerpt from the definition provided by OSHWA [1]: > Open Source Hardware (OSHW) is a term for tangible artifacts — machines, devices, or other physical things — whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things. Wikipedia's article on Open-source hardware has the following statement [2]: > Hardware design (i.e. mechanical drawings, schematics, bills of material, PCB layout data, HDL source code and integrated circuit layout data), in addition to the software that drives the hardware, are all released under free/libre terms. I don't want to speak for anyone else, but my hope is that the ecosystem around FPGAs, including the VHDL/Verilog, toolchain, design and manufacture, will all be free/libre so that the underlying chips will be treated as commodity. Even if the chips themselves need massive infrastructure to create, if they're treated more like a fungible commodity then we could see 'clones' pop up and not be so dependent on a select few companies. In terms of DIY manufacture, I think Sam Zeloof has been doing some "Homemade Silicon ICs" [3] but I don't have a good sense if that will ever catch on or be within reach of the average hobbyist. Maybe a bit off-topic but @ico_TC has this to say on Twitter about it [4]: > I had discussions with 4 different FPGA vendors. For them it does not make sense to invest cash in improving the open source toolchain, as it does not sell enough additional chips to justify the cash investment. [1] https://www.oshwa.org/definition/ https://www.oshwa.org/definition/ [2] https://en.wikipedia.org/wiki/Open-source_hardware https://en.wikipedia.org/wiki/Open-source_hardware [3] https://www.youtube.com/watch?v=XrEC2LGGXn0 https://www.youtube.com/watch?v=XrEC2LGGXn0 [4] https://twitter.com/ico_TC/status/1269155001999507456 https://twitter.com/ico_TC/status/1269155001999507456
mips_avatar 6y ago
I am waiting for FPGA to have it's arduino moment. I know there are attempts, but they all seem to not have achieved adequate depths to really dig in to the exciting parts of FPGA development
mupuf 6y ago
Thanks for the feedback, everyone! I fixed up quite a few things based on it! I'll keep on working on the code and hopefully will have some more tangible to share at the end of the summer :)

98 points by caution 6y ago

qppo 6y ago

> The bad part is that most of C/C++-compatible HLS tools are proprietary, and open source ones are either Scala-based (Chisel, SpinalHDL) or seem to be academic toy projects. Why is Scala a problem?

coreyoconnor 6y ago
(scala dev here) Scala has a history of embedded domain specific languages that are difficult to understand. (Rather like Perl now that I think about it.) This is not universal in scala EDSLs but definitely exists. So it's a fair concern in general. IMO Chisel is a nice EDSL so, in this context, the concern is unwarranted.
TD-Linux 6y ago
I think the article author is mixing up HLS tools and HDLs. HLS tools convert some subset of C to a hardware implementation, and thought that Chisel/SpinalHDL were converting Scala to hardware. But they are really just HDLs implemented as a DSL within Scala, much like Migen uses Python but does not execute Python code on the FPGA.
- mupuf 6y ago
  Yeah, I definitely jumbled both in the same basket. I should rename that into "higher-level languages" and introduce both HLS and HDL there. Thanks for the feedback, I'll make some changes to clarify my thoughts!
microcolonel 6y ago
In addition to Chisel and SpinalHDL, BlueSpec is now open source! [0] Among the available options, I remember people being very happy with BlueSpec even before, and now you don't really have many excuses. [0]: https://github.com/B-Lang-org/bsc https://github.com/B-Lang-org/bsc
- jakear 6y ago
  Nice! I used it in college and took a liking to it, it was pretty easy to write a full multi core riscV processor with mmu/etc even as my first exposure to hardware design. The compile times were killer though. Has much progress been made there?

Teknoman117 6y ago

> This enables a $37 part (XCA712T) to be able to fit over 3 Linux-worthy RISC-V processors running at 180 MHz, with 720 kB of block RAM available for caches, FIFOs, or anything else. The $100 Alchitry Au has an XC7A35T and 256 MB of DDR3. Currently waiting for them to come back in stock, they're super neat and are open hardware. They're basically the successor to the Mojo V3.

jack12 6y ago
> are open hardware. Are they? I only see PDFs of schematics on their website, and no claims of being open. Of course with a breakout board like that there isn't really any secret sauce in the "source", just the expertise, trials and errors, and grunt work of layout. At that same level of "schematics available" dev boards, another option for a XC7A35T and 256MB DDR3 are the ones on aliexpress for $50, https://github.com/ChinaQMTECH/QM_XC7A35T_DDR3 https://github.com/ChinaQMTECH/QM_XC7A35T_DDR3, though I don't think they have the transceiver pins exposed and are bring-your-own-jtag-programmer. All the IO is via 0.1" headers, which are going to be lower integrity but a LOT easier and cheaper to use. There's also a $99 XC7A100T board, https://github.com/ChinaQMTECH/QM_XC7A100T_WUKONG_BOARD https://github.com/ChinaQMTECH/QM_XC7A100T_WUKONG_BOARD, with 256MB DDR3, a gigabit ethernet phy, hdmi port, 0.1" headers and PMOD headers, and with some transceiver pins exposed.
- rjsw 6y ago
  Why can't people build more dev boards with 32-bit wide DRAM ?
  - _sbrk 6y ago
    Why do you want it, and how much are you willing to pay?
- mupuf 6y ago
  Thanks for the links. I'll make sure to check them out in details!

rjsw 6y ago

The title suggested to me that they were looking for Linux/BSD drivers for IP within an FPGA, either connected to a CPU using PCIe or for an ARM/FPGA hybrid.

mshockwave 6y ago
i agree it's kind of confused. But from a compiler dev perspective (which i think is closer to OP's perspective), driver means a piece of software that put together components / tools and bootstrap the processing pipeline
imheresamir 6y ago
Is that not what the author is referring to? From the readme of his LiteDIP project[1]: "Plug-and-play LiteX-based IP blocks enabling the creation of generic Linux drivers. Design your FPGA-based SoC with them and get a (potentially upstream-able) driver for it instantly!" [1]: https://gitlab.freedesktop.org/mupuf/litedip/ https://gitlab.freedesktop.org/mupuf/litedip/
- rjsw 6y ago
  There isn't anything there apart from the readme. I built a descriptor block into a FPGA design about 15 years ago, this was for PCI so I could put it at a fixed offset into the BAR for every device. I don't see how the "get a (potentially upstream-able) driver for it instantly" would work. Someone would still need to write a driver, you just get a way to probe for whether to attach it or not.
  - mupuf 6y ago
    Sorry about that, the project is still very early. Check out the fan_wip branch for actual code. The point of LiteDIP is to provide both the IPs, and their drivers. Also, rather than needing IPs to be located at a certain address in any sort of bus (PCI BARs, wishbone, ...), litedip exposes the list of IPs starting at address 0 along with their version and relative address. The driver then lists these blocks, and either has a driver for this block's version or not.

throw_Away1337 6y ago

I don't know a lot about this topic but I had an introduction class where we also covered FPGAs. The prof offering the class though is really sufficient in this topic and has developed this tool: https://github.com/esa-tu-darmstadt/tapasco/blob/master/README.md https://github.com/esa-tu-darmstadt/tapasco/blob/master/READ... As you are saying it seems like just a science toy project but he was quite convinced that it already works pretty good and good enough for fourth-semesters to work with it. The tool itself is a high level c++ tool-chain to develop for FPGAs. You should definitely check it out :) Then there's also Bluespec Verilog which has been open sourced not too long ago. It is way more abstract than Verilog or system Verilog and in comparison to them it's a pleasure to write in. But it's definitely not as high-level as C++.

inamberclad 6y ago

Open hardware is relative. Most of these parts still require the xilinx or altera tools. Only the ice40 and ECP5 chips from lattice are really functional with an open source toolchain. I'm quite grateful to lattice for that, even if they had no part in it, they haven't been inhibiting the open source community's efforts.

mupuf 6y ago
My understanding was that open hardware stood for "open PCB design", with the idea that a community could be made around it to improve the design for later revisions. Open toolchains are another topic, and indeed, Lattice FPGAs are now super attractive because of it! Hopefully, project X-Ray will bear fruits soon and I can ditch Vivado, at least during development! In the end, a hardware design using Lattice or Xilinx FPGAs is not more or less open. Discrete components will always be proprietary (unless your name is Sam Zeloof). What matters is pushing the boundary further and further, and for this, FPGAs are amazing!
- abetusk 6y ago
  Open Source Hardware is not limited to just the PCB design. Here is an excerpt from the definition provided by OSHWA [1]: > Open Source Hardware (OSHW) is a term for tangible artifacts — machines, devices, or other physical things — whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things. Wikipedia's article on Open-source hardware has the following statement [2]: > Hardware design (i.e. mechanical drawings, schematics, bills of material, PCB layout data, HDL source code and integrated circuit layout data), in addition to the software that drives the hardware, are all released under free/libre terms. I don't want to speak for anyone else, but my hope is that the ecosystem around FPGAs, including the VHDL/Verilog, toolchain, design and manufacture, will all be free/libre so that the underlying chips will be treated as commodity. Even if the chips themselves need massive infrastructure to create, if they're treated more like a fungible commodity then we could see 'clones' pop up and not be so dependent on a select few companies. In terms of DIY manufacture, I think Sam Zeloof has been doing some "Homemade Silicon ICs" [3] but I don't have a good sense if that will ever catch on or be within reach of the average hobbyist. Maybe a bit off-topic but @ico_TC has this to say on Twitter about it [4]: > I had discussions with 4 different FPGA vendors. For them it does not make sense to invest cash in improving the open source toolchain, as it does not sell enough additional chips to justify the cash investment. [1] https://www.oshwa.org/definition/ https://www.oshwa.org/definition/ [2] https://en.wikipedia.org/wiki/Open-source_hardware https://en.wikipedia.org/wiki/Open-source_hardware [3] https://www.youtube.com/watch?v=XrEC2LGGXn0 https://www.youtube.com/watch?v=XrEC2LGGXn0 [4] https://twitter.com/ico_TC/status/1269155001999507456 https://twitter.com/ico_TC/status/1269155001999507456

mips_avatar 6y ago

I am waiting for FPGA to have it's arduino moment. I know there are attempts, but they all seem to not have achieved adequate depths to really dig in to the exciting parts of FPGA development

mupuf 6y ago

Thanks for the feedback, everyone! I fixed up quite a few things based on it! I'll keep on working on the code and hopefully will have some more tangible to share at the end of the summer :)