StarFive Dubhe 64-bit RISC-V core to be found in 12nm, 2 GHz processors | Hacker News Reader

StarFive Dubhe 64-bit RISC-V core to be found in 12nm, 2 GHz processors

cnx-software.com

76 pointsbtdmaster23 comments

This will be the first RISC-V chip I have heard of that implements the popcount instruction.

To my knowledge it is not required in any standard profile, so getting a compiler to generate the instruction will be messy.

When run on a chip that does not support the instruction, typical 10x optimizations become 10x pessimizations instead.

Will we see the rise of Libc shims soon like those for JavaScript? RISC V feature support looks notoriously fragmented.

Does it? It's something I constantly worry about, but so far distributions are holding steady to RV64GC which essentially all 64-bit RISC-V cores support. A few support some proprietary extensions, but those can be ignored by most. The Dubhe core claims to support some of the newly ratified extensions, which if true is great exactly because they are standard and thus doesn't represent fragmentation. I expect of course that libc eventually will start supporting these extensions _where they are present_ but not mandate them.

Except for proprietary extensions, I don't think it will be very different of the x86 world where processors can have a different number of cores, HT, MMX, 3dNow!, SSE(1,2,3,4...), AMX...

These extensions didn't destroy x86. I don't think it will be different with RISCV.

It is very, very different.

X86 extensions get added onto the sum total of almost all the previous extensions, so that the number of variations to support has grown about linearly with time. RISC-V extensions are more or less all independent, so that the number of variant targets explodes exponentially as they are added to.

>explodes exponentially

Nit pick: it explodes factorially, which is worse than exponential. The superset of a set of N elts is N!. (If order is meaningful (unlikely here), it's slightly worse, which is all permutations of each member of the superset. But that's only ~exponential and is quickly swallowed by the factorial).

It is not different in the sense that my compiler can generate code that runs on RISC-V and runs faster on RISC-V with specific extensions. Binary compatibility, in practice, is not lost.

There is no requirement to execute instructions defined in an extension not supported. So, it means building for RISC-V is necessarily complicated.

Worse, if it traps and emulates instructions, then optimizations using extension instructions become radical pessimizations.

Whatever the target processor is, when we need performance we recompile for that specific target. And whatever the target processor is, if you need portability you compile only with extensions widely used.

It's the exact same problem with x86 or arm.

So.. yes, currently RISC-V is mostly made of isolated extensions, but the goal is clearly to create groups of extensions that will be widely supported.

If you're building a chip for a server, workstation, laptop, smartphone, then you'll want to adhere to a platform spec profile.

RVA22[0] is the first such profile, and among other important things which go a long way to ease cross-vendor software compatibility, it does require RVA22U and RVA22S, which in turn require a set of extensions.

[0]: https://github.com/riscv/riscv-platform-specs/blob/main/risc...

Maybe. The technology for "JIT" (i.e. AOT just prior to the program starting) is also relatively mature, so maybe it could go that way.

However a lot of these are embedded targets so I don't think we are even close to needing to worry about at least some of these things yet.

Most risc-v cpus stick to the standards, so I'm not worried.

Are the vector ops variable width? And 1024 bit?

The RISC-V standard is quite expansive, I can't tell the intent in the article.

It is a 128bit wide vector design. Which means the wdith of actual vector register is 128bit. The 1024bit figure is due to register grouping of up to 8 vector registers which is mandated in the spec.

GlobalFoundries could be a big player in this market segment. Their lithography tech isn’t bad at all.

It has stopped advancing. That's kinda the definition of bad in semiconductors.

Trailing-edge nodes are not "bad". They have plenty of use and do get improved over time. Beyond that, stuff like 7nm and 5nm is simply not viable for anything that's not going to be fabbed in huge amounts.

A fab that isn't advancing its leading edge process at the rate the industry is moving ahead is, by definition, falling behind its competitors. When they can no longer provide a competitive process relative to other fabs, they will lose customers. GloFo is losing / has lost AMD as a customer. AMD saw what was happening and migrated their CPU cores to TSMC in order to remain competitive. I think that's pretty damn bad for GloFo! Just look how long it took Intel to recover from its missteps on their 10nm process. Catching up when you've missed a couple of process nodes is neigh impossible for a fab, as they start losing the cash flow needed to reinvest in process development, which causes them to fall further behind and lose yet more revenue. How is any of this not "bad"?

Yeah, okay, I know. 12/14 nm on GloFo is still perfectly usable for this class of chip and plenty of other applications.

Old != bad.

28nm and 40nm are going to be common for a long long time, too.

Only leading edge processes can command a price premium, and for some products (like the high performance CPUs that Intel and AMD make), trailing processes are not economically viable. If a process is not economically viable, I'd consider that to be one possible definition of "bad". In the case of Global Foundries, they lost their anchor customer AMD who now only uses them for an I/O die that will migrate off GloFo's process as soon as their wafer supply agreement permits. That's pretty damned bad and does not bode well for GloFo's continued viability.

GloFo is booked solid through to 2023[0], and that’s without AMD’s volume. Again, not everything needs to be on leading edge nodes. Since when are trailing edge processes not viable? I have no idea where you’re getting that idea from. For example, in Q1 2021 TSMC made more than 50% of its revenue in processes older than 7nm.[1] Just so you know, TSMC intends to keep ramping up >7nm production for a few more years. There is so much demand for all kinds of nodes that it’s hilarious that you’re still trying to make this argument.

0: https://www.cnbc.com/2021/10/30/globalfoundries-ceo-were-sol...

1: https://www.anandtech.com/show/16621/tsmc-q1-2021-process-no...

We're talking about processors here, not random semiconductors that have no market incentives to move to newer process nodes.

Let's say you've got a team of engineers ready to design the next generation of their 64-bit RISC-V core. You've just completed your 12nm design, and are trying to target where the market will be in 24-48 months when your new design is finished. Are you going to:

  a) design a new core targeting the same 12nm node your previous design was built on
  b) target a newer 7nm node that gives you:
      1) lower power from the node shrink
      2) higher clock speeds thanks to the node shrink
      3) higher performance thanks to increased execution resources made possible because of the node shrink
      4) lower cost thanks to smaller die sizes made possible by the node shrink

Most teams of electrical engineers will select option (b).

I am not saying there is no value in older semiconductor fabs. I am saying that for CPUs, there is serious market pressure is to move on to more advanced nodes, and that for a company like GloFo it is becoming less competitive and falling behind in the market for CPUs. Personally, I consider this a bad thing for a fab that came into being in part because it was once a performance leader with high end AMD CPUs. Sure they can change what market they're targeting - that's just survival - but it's generally a bad thing to lose what was once one's greatest strength.

Reply on news.ycombinator.com