Hacker News Reader

Comment by wmf | Hacker News Reader

I guess this will have to be limited to accelerators because a CPU/GPU/NIC/etc. in an FPGA will never be remotely as efficient as a real CPU/GPU/NIC/etc.

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.

View on HN

I don't think it's necessarily about using an FPGA on the cloud for your crypto miner as much as it is about reducing the costs (not specifically monetary) associated with hardware design in general. As the blog states: "Access to hardware: Hmmm. This is still a problem." The traditional reasoning would argue that spinning a chip is so prohibitively expensive, so why bother reducing other costs for the open source community?

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.

An FPGA is a lot slower than a real ASIC in the same process node (one order of magnitude of slowdown at the very least - even two is far from uncommon!). OTOH, this means you can make an ASIC version of your logic in older process nodes that can be fabbed a lot cheaper than anything on the cutting edge, and still come out quite a bit ahead over the FPGA itself. This turns FPGA's into tools for quickly iterating on a design and little else, because for real use ASICs are just too good of a deal to pass up.

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.

> This turns FPGA's into tools for quickly iterating on a design and little else, because for real use ASICs are just too good of a deal to pass up.

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.

Well, yes and no. Yes, FPGAs will always be slower than real HW (for the foreseeable future at least). But you can use a design taylored to your application (an accelerator indeed), whether it is a CPU, a GPU, a NIC or anything else, and get more performance out of it than silicon that's available today.

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?

I've generally wondered about extensions for RTOS support. Special kinds of priority-encoders off registers for flags; shared-memory locks; -- that sort of thing.

Why do you think an open source CPU design can't be manufactured by a fab?

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.

Why do you think an open source CPU design can't be manufactured by a fab?

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?

Reply on news.ycombinator.com