Unleashing Open-Source Silicon
opensource.googleblog.com
opensource.googleblog.com
That said, I do believe significant improvements are being achieved to lower the barrier for HW development. One thing that is not often mentioned is that even for experienced hardware developers (like myself) it is very hard/time consuming to fully implement the full stack of technologies required to accelerate computation on a PCI express connected FPGA board.
I haven’t followed recent trend of HLS, thus I can certainly say that with the traditional approach verilog/SV, it would be only a handful of people that could actually make use of those FPGAs.
The physical design in an fpga solution is pretty much done for you. You've also got a nice package (power, warpage, SI all done). In an ASIC you start this enormous task from scratch. You've also got to implement (and interface with) a huge amount of test, which again, is mostly done for you when you purchase your working FPGA.
Not to mention the fact that there's little margin for error with an ASIC, there's no second chance to try again without spending a load of money. So the test and verification of your circuits is much higher. (I know your said "working" design but there is no such design that is guaranteed to work when changed).
Yep, you just change the target platform and re-compile!
Getting custom silicon in older processes (>150nm, but even 90nm has come down dramatically and that's a pretty modern process) just isn't that expensive anymore. It's under $50K, and can be under $5K if you catch a "shuttle" that one of the fabs runs.
The VLSI CAD tools, however, are ferociously expensive. Even the old Tanner tools are now being flogged by Mentor for north of $100K. And they're probably the cheapest around.
We're not even talking heavy digital--old 2um or 5um (especially metal gate since they have 18V voltage tolerance) processes are interesting for analog audio. Guitar pedals still use analog bucket brigade delay chips that haven't been manufactured for decades. At $5K, you could make your money back on a boutique pedal if you sell 100 of them. At $50K that gets dicey and at $250K that will probably never happen.
The ability to slap a couple hundred transistors down on a chip, simulate it and get it manufactured for less than $5K would enable a lot of interesting, low-volume stuff--look at what happened when PCBs got so cheap.
Right now, the entire electronics industry is constrained by the fact that volumes are "millions or bust".
That's why it was particularly frustrating to see DARPA missing the boat to try to make more digital stuff happen. We have an excess of digital. We have vast quantities of digital. We have so much digital people don't know what to do with it all.
What we don't have vast quantities of are interesting sensors, oddball RF designs, or extremely low power things. Note that these are all analog.
Throwing money into an open-source VLSI toolchain would do more to relieve DARPA's VLSI bottlenecks than anything else they could do.
It is hard for me to take their words all that seriously when they are holding back some of the most important pieces from their users.
Ditto for Microsoft.
These "apps" are all based around interaction with Google services. Maybe they could release open source versions of those, but then the users would be left with the hassle of having to pay Google for API accesses by the open source code they're running. Most users would simply not bother, and stick to whatever Google is providing for free.
I should also point out: often, with this type of project (in-the-open development of a client for a paid service) the client comes with some sort of stub emulator for the service. FOSS developers can test their changes against the emulator, and then submit PRs, which then get run by CI against the real service.
Because sustainable open source rarely works that way. Sustainable open source projects focus on three things: (1) identify the bits that are common across many applications, (2) establish an open source standard for those bits, (3) sustain the bits by making it easy for other people/orgs to use them & contribute to maintaining them.
Edit: Sometimes a tool like Blender is open source and feature complete. So it seems like “the whole thing” is open source. However, in those scenarios the tool usually replaces a very expensive proprietary tool (Maya, in the Blender example) that is a single step in a larger business process (like making a 3D animation).
I understand not open sourcing their secret sauce (e.g. search algorithms), but they have a ton of other products that could absolutely be open source without any negative financial impact. It's things like this that make me seriously doubt their commitment to open source.
Lots of open source repos rarely see any activity and the the world is still so much better because people fork it, read the code, or just use it as is.
GNU grep sees almost no activity and it’s done more for people than kubernetes has.
From the article: "By Steve Hoover, Redwood EDA, Google Summer of Code mentor".
If Microsoft open sourced Windows would you complain that it wasn't really open sourced because they didn't open source Microsoft Office?
Such extreme exaggeration makes it difficult to take your comment seriously.
This is the case for me, for example. I never release software without source.
Actual open-source hardware (if you can indeed even use the phrase "open source" for this) would be distributing schematics of silicon chips online, so that anybody with the means to fabricate them could do so. I see this more akin to the "openess" of the 3D printing community. If technology to "3D print" silicon chips becomes available, that will be the turning point.
I do see the point you're trying to make about cost of manufacturing, but there are already a number of "printable" circuits that a 3d printer can put together to build your own chips.
And whilst the kind of circuits I've printed onto clothes don't quite match full-scale chip production, it's an active area of research [0], so I wouldn't say it would be too long before it reaches consumer hands.
[0] https://www.machinedesign.com/3d-printing/3d-printed-flexibl...
https://www.instructables.com/id/3D-Printing-3D-Print-A-Sold...
There are several groups trying to bring this awareness, for example FSIC is pretty interesting (https://wiki.f-si.org/index.php/FSiC2019)
Woah, really? This seems ... impossible, right?
Its a cool tool, but right now it's more of a productivity aide for people who already understand Verilog/VHDL rather than an enabler for software engineers.
Here's the thing:
Knowing VHDL/Verilog will not:
- Get you a job with compensation on the same level as ML/Web Dev.
- Magically make your tech/startup work better
- Fulfill buzzword requirements for investors
These sort of low level tooling is tremendously difficult to make profitable unless you already have some sort of vendor lock-in i.e. silicon, or an application that is extremely demanding in terms of efficiency or speed e.g. High Frequency Trading, network switches, dot-product-machines (commonly known as ML) and crypto hardware. Unfortunately any other applications for FPGAs tend to closely related to the embedded space (robotics, aerospace) and again it's significantly more annoying to monetize compared to e.g. a SaaS oriented around ML. Especially so it you are not a massive corporation with deep pockets.
The closest we have come to a high level tool for FPGA synthesis is reconfigure.io but they got acquired and is now effectively dead.
CPUs and ASICs have become too powerful and too cheap. Even with Moore's law tapering off, the gains provided by FPGAs are still too narrows. Electrical engineers are cheap. Physics have not changed much in recent decades. A couple computer architecture courses is more than enough to bring an EE graduate up to speed (referring to FPGAs here, ASICs are another story)
Also there's not necessarily much of a performance gain, some tasks are not good candidates for being implemented in hardware (as a general rule you need a lot of parallelism to make it worth it). As an overly simple example, implementing hardware RSA and hoping for a significant speedup doesn't make sense because there isn't really much parallelism and it's usually only used to encrypt keys, but something like AES or SHA might benefit from a good hardware implementation because there is much more parallelism to be had and they are used to encrypt much larger amounts of data.
To add even more complexity, the compilers can be obscenely finicky with optimizations.
[2] https://www.chisel-lang.org/
[3] https://www.chisel-lang.org/firrtl/
https://www.xilinx.com/products/design-tools/vivado/integrat...
Silly or not, they definitely see a market there.
Khronos is pursuing OpenCL to FPGA targeting, and you can do it with C++ via SYSCL.
Intel also has their offerings,
https://software.intel.com/en-us/oneapi
And LLVM can also target some directly,
Then there are the same old questions of efficient access patterns to DRAM, bus bandwidth, and so on.
See e.g. http://users.ece.utexas.edu/~gerstl/ee382v_f14/soc/vivado_hl... : basically the data structure has to be defined at compile time, or at least "auto" allocation; you can't dynamically allocate silicon.
ARM and x86 are not quaking in their boots by any measure. I certainly haven't seen Google itself rushing to ship RISC-V devices or provide RISC-V cloud services at scale. I doubt there's much demand for either compared to ARM and x86.
Consider MIPS: it is another open ISA and it has good toolchain, silicon, and OS support, but ARM still rules on mobile and x86 still rules the desktop and server world.
In the case of Apple at least, they already design their own ARM CPUs and there is no clear advantage to switching to RISC-V or MIPS.
However, an Apple CPU that combined ARM and x86 compatibility might be useful in Apple laptop and desktop PCs.
Open source software has been successful at creating generic infrastructure, possibly because generic software can support large communities. I still don't see how to create that kind of effect in hardware.
For instance: a custom RISC-V CPU with extensions for machine learning, whether it is for prototyping or not. Or a NIC with some complex routing capabilities, etc. And of course, I guess that various accelerators are indeed the main driver behind this.
I guess you could also run one of these devices you named without efficiency in mind: hardware/software validation, trusting trust, profiling, etc.
But the big part might also be: access to big FPGAs at a fraction of the cost you usually need to shell out to get them, which in turns enables more regarding design verification, etc. for Open source HW, and maybe bypass the annoying vendor-specific tools for a cleaner API, with a hassle-free experience. Can we directly modify the bytecode with this?
There are economics of scale at play but the entry level keep going down while the market for open source grows.
I don't expect open-source ASIC to suddenly come to life and compete with the latest Intel, but I could see an open and verifiable design taking the place of microcontrollers in many places where cost is more a factor than performances. Or rather, where you need a known level of performances but that anything above that threshold is waste: HDD controllers, ethernet controllers, power supply controllers, etc...
I am predicting that at one point a Chinese fab will manufacture a batch of an open source competitor to some ARM Cortex chips and that it will catch up because of a mix of inferior prices, open doc and community and ideological reasons.
That's possible but it doesn't enable the feedback loop where you can modify it, use your own modifications immediately, then contribute them back to the community. FPGAs support that loop, but only for accelerators.
There are economics of scale at play but the entry level keep going down
Everything I've read says that the cost to tape out is going up.
I could see an open and verifiable design taking the place of microcontrollers in many places where cost is more a factor than performances.
Yeah, but why would a community form around that? What's cool about saving a few pennies for some chip companies?
But this can only be fully realized if the "high-level" part of ASIC design becomes a lot more straightforward than it is today. Which in turn requires significant progress in open source EDA tooling.
The dynamic reconfigurability lets FPGAs have a niche that can't be easily filled by ASICs. Being able to treat FPGAs like any other software target (albeit with a esoteric language exosystem) was a game changer in a lot of ways. I've heard of systems that reconfigure at runtime as well.
Unlike the software community where we have nice open source libraries to do the useful and boring bits of of your software stack, more or less everything that's more complicated than a floating point adder is IP. (ARM CPU, PCIe controller, Ethernet controller, Internal fabric, DRAM controller.) Now you can go and buy this IP from other companies like ARM and Synopsis, but it costs money.
Then once you have made an architecture you like, there will be another group of companies wanting hundreds of thousands of dollars for their simulation tools (which are painfully outdated.) And they can charge so much because creating silicon is really expensive!
We have a long way to go on both of these fronts, because making open source hardware blocks and open source toolchains is much harder than it sounds, and for what benefit? It's still several million for masks.
For a startup trying to make innovative hardware however, Those things can mean faster development times, fewer engineers needed, and reduced IP royalty fees. For the industry, it gives students a lower barrier to entry to the field, so that when they come out of college they can be ramp up quicker. For me as a hardware engineer, it makes my life better, as it gives me hope that some day my tools won't be outdated and overpriced.
You don't get to call yourself generous. If it's so obviously self-serving then it's not generosity at all.
It doesn't make sense to rent a "cloud" FPGA because it is ineffective. You get a vendor-locked solution with poor performance written in slow Python and Javascript. The code is on Github which means it will be buggy and always in "under construction" state (try using desktop Linux to understand what it means). As the chip is in the cloud, cloud operator can see and steal your secrets. The latency to send data to the cloud is very high. You cannot debug the chip and cannot connect a logic analyzer to it. You cannot make a hardware product with "cloud" chip. You cannot connect sensors to it.
This is only usable as a toy to play with FPGA from browser. You cannot use it to control a CNC machine or video surveillance system, for example. You cannot make a guitar pedal (that someone have mentioned in comments below) with this.
What developers need is cheap powerful FPGAs that they can buy and connect directly into an USB port, not a toy in the cloud.