Hacker News Reader

Comment by monocasa | Hacker News Reader

Does anyone here know why OpenCores atrophied so much between now and then? It had so much going for it.

I think that it's really hard for stuff like this to take off, to fab a real CPU can cost many hundreds of thousands of dollars of NRE, to fab a piece of open source software the NRE is essentially $0 - there just aren't enough (maybe no) people with the interest and time to spend on a large open source project AND hundreds of thousands of dollars to throw at it

Fab isn't the real issue. ARM Holdings doesn't have a fab. They license IP in HDL form to people that have fabs. And those people with fabs would like not to pay license fees. So why do they pay? Ecosystem.

So let's say your team has what it takes to design and validate the HDL for a processor microarchitecture that implements some un-encoumered ISA with performance that is attractive and a sufficiently short errata list. Then published the HDL under some free-as-in-speech license. You still have to get gcc, llvm, and gdb to support you, at a minimum. And then you want the hardware debugger people to support you. They will support you if you get enough users, if you get enough support from tool makers you will get users. The trick is not running out of money before the ecosystem spins up and your competition releases a more attractive core.

ARM did fab their original design(s) ... (on someone else's fab)

(having done this ....) getting gcc/gdb/linux/etc working for your new architecture is something you will have done long before release your gates - both on your architectural simulator and you've probably booted linux at least once to a prompt on your gates (or at least HDL)

I've been on both sides, I found bugs in the original 29k bringing up unix (pre-linux) on the architectural simulator that were in the real chip, and as a logic designer helped design a new CPU and bring up linux on it

Anyone who seriously has a new CPU already has that ecosystem in place at the point they announce their CPU (and is probably busy trying to push their changes upstream to the gcc/llvm/glibc/uboot/linux/etc trees the day they announce to prove they are real)

But I agree the trick is to not run out of money ....

would you be interested - and self-motivated - to help get an entirely libre RISC-V SoC up and running, that has the building blocks of a VPU and also enough Vector Processing in some form to do decent 3D graphics as well? tools are paid for. access to foundries is available (20nm, 28nm, 40nm). engineering resources via the shakti project are also available. http://rhombus-tech.net/riscv/shakti/m_class/ if so do get in touch, luke.leighton@gmail.com

I don’t think it was ever viable to begin with. Remember that this was when “Linux” was what “Bitcoin” is now: a word you stuck in your company name to boost your share price based on nothing but bubble hype. That looks to be what happened here. Also, it takes stupefying amounts of capital to be in the CPU business, especially when starting from scratch, and if that looked possible at one point, it certainly didn’t when the dotcom bubble ended.

I think the timing is pretty perfect for a RISC-V open eco-system to flourish in a Cambrian manner.

With silicon scaling laws getting walls, Intel's ability to have an efficient general purpose CPU for every workload is fading. The only way to provide better performance is to provide specialization, now.

Processing will specialize in the following:

* databases: SQL projections in special hardware data slicing CPU instructions. Hardware-accelerated hashing, sorting, filtering.

* dynamic languages: Special code caching for JITted code. Memory models that won't have to be emulated. Memory barriers and copy on write to help the GCs do the work.

* AI: We're already seeing this with Google's TPUs: Low precision tensor operations. We're going to see more specializations inside this segment too. Tensorflow today has CPU, GPU and TPU backends. In a stable high volume configuration such as vision for an autonomous car, why not provide a fourth backend for a Tensorflow pipeline: VHDL/Scala?

* IoT/Sensors: Extremely low power modes, on-chip LoRa.

* Network: this is already happening with microsoft using FPGAs to help do the routing. Once settled, some use cases will have their silicon edition.

----

This will lead to a thining of the margins of Intel, NVidia and ARM, to the fragmentation of the monopolies, and less money will go to the lawyers.

Intel's deceptive behavior got me worked up enough to order a SiFive SoC board today just to support their efforts, and to see if I can make something worthwhile on a RISC-V chip. It's only $59, too.

I'm kind of excited to try something new in a way that I haven't been for a few years, so there's that, too.

I don't really know, but maybe for one thing 2001 was still when x86 was destroying its RISC competition and getting much faster every year, and maybe before it was obvious ARM would be huge; there wasn't appetite for alternatives, let alone room for bottom-up adoption of an open architecture?

OpenCores seems to still exist as does a relatively recent (2015) splinter LibreCores/Free and Open Source Silicon Foundation (FOSSi). Wikipedia says OpenCores was always a commercial organization; maybe it was not entirely clear how other commercial entities could relate? OpenCore's OpenRISC is LGPL/GPL which could have further put off commercial entities (whether it should have or not)?

There's an associated annual conference https://orconf.org/ which seems to be about any open chips topic now, unsurprisingly including several RISC-V talks last year.

Reply on news.ycombinator.com