FPGA: Why So Few Open Source Drivers for Open Hardware?
mupuf.org
mupuf.org
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!
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/
[2] https://en.wikipedia.org/wiki/Open-source_hardware
In the case of FPGA boards, OSHW would thus require "mechanical drawings, schematics, bills of material, PCB layout data, and integrated circuit layout data" given that no HDL source code is present in it.
Seems like I have been a little loose in my description, but at least I did not completely miss the point. Accuracy is however needed, I'll try to find another formulation or link to the pages you sent for people to see that it is a little more complex!
Under the section "3. Necessary Software":
> If the licensed design requires software, embedded or otherwise, to operate properly and fulfill its essential functions, then the license may require that one of the following conditions are met:
> a) The interfaces are sufficiently documented such that it could reasonably be considered straightforward to write open source software that allows the device to operate properly and fulfill its essential functions. For example, this may include the use of detailed signal timing diagrams or pseudocode to clearly illustrate the interface in operation.
> b) The necessary software is released under an OSI-approved open source license.
My interpretation of that would include HDL source code.
Why is Scala a problem?
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.
Thanks for the feedback, I'll make some changes to clarify my thoughts!
Among the available options, I remember people being very happy with BlueSpec even before, and now you don't really have many excuses.
The compile times were killer though. Has much progress been made there?
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.
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, 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, with 256MB DDR3, a gigabit ethernet phy, hdmi port, 0.1" headers and PMOD headers, and with some transceiver pins exposed.
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++.
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 :)
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.
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.