It's not an improvement over $999, it's an improvement over ($999 + $1999) = $2998 because it has PICe and USB and so forth all on one SoC and board.
That's a 4.5x price reduction (or 77.8% off if you prefer) in three years.
The price/performance increase should be bigger than that because of the ~50% increase in IPC and also hopefully a ~33% increase in clock speed (they don't seem to have announced that but it should be around 2 GHz)
Also it's a just a little unrealistic to expect something that will have taped out 6 to 9 months ago to have extensions that aren't even at draft 1.0 status yet, let alone ratified. Any chip with those is going to be 18 to 24 months away.
>Also it's a just a little unrealistic to expect something that will have taped out 6 to 9 months ago to have extensions that aren't even at draft 1.0 status yet, let alone ratified. Any chip with those is going to be 18 to 24 months away.
Together with claims earlier this year that there'd be some ratified V (a 1.0 draft?) by September and they'd have chips ready pretty much immediately.
What I understand at this point is that this simply hasn't happened, but I do not know the specifics.
I don't believe they've ever said they'd have chips available immediately. That would be some kind of time travel.
What I believe they've said in the past is they'll have cores available for licencing immediately, and indeed the "VIU75" with "Vector Intelligence" was announced last week. Customers will be able to sign contracts now, and get preliminary near-1.0 RTL to use in FPGAs for testing and software development. By the time the customers are ready to tape-out in six or twelve months the final spec-compliant RTL would be available.
Neither V nor B are ratified, nor are they part of the Unix platform standard (and hopefully never will be).
V is close, B is not. There are exactly 0 chips or even IP on the market with standard B (which is really a family of sub-standards), but there are chips with pre-standard V (alas, a few of them aren't compatible with the current draft - the perils of running ahead).
Overall, yes you are right, this is most useful for people interested in seriously evaluating RV64GC and/or porting code. It's a one of the necessary steps on the path to more adoption, but not the last one.
Do you have a rationale for this? I understand that:
* The unix platform standard is a relatively fat selection of extensions already.
* The nature of V's flexible width allows it to be implemented in very small scale to very large scale, so it would have little impact on the complexity of the minimum platform, while allowing great benefits as it scales up to larger platforms.
1. Cores already exist or are coming that satisfy the existing platform. They would be obsoleted by a change in the requirements.
2. RV64GC is already quite big. Piling more requirements onto it will make it harder to introduce small cores.
3. V is pretty complex and I don't agree with your assertion. In contrast I'm aware of cores with vector where the vector part takes up 50% of the die and does exactly nothing for the scalar apps that don't use it. I'd much rather spend that silicon on more IPC or a 2nd core.
The price really isn't that outrageous. Consider the use-case: this is a mini-ITX form-factor with a standard power supply, M.2 slots, a PCIe adapter, etc. This is designed for desktop workstations.
It comes with the CPU, motherboard, and RAM, all in one package.
When you sum up the costs of those in your typical desktop PC workstation build, it's not really that far off.
>It comes with the CPU, motherboard, and RAM, all in one package.
Unfortunately, the RAM not being socketed means you're limited to 8GB, which disqualifies this machine as workstation.
Low CPU performance is tolerable, system chocking on low RAM isn't. I'm suffering on a laptop that "only" has 16GB RAM, and this is despite minimizing the load by alternating between Sway and i3 depending on mood on boot. Editor, Browser (unavoidably heavy, with a ton of tabs open as part of the workflow), PDF viewer, Music player and little else. Everything is bloated these days.
I don't see how 8GB can be tolerable as a workstation. It really is a deal breaker.
Hah! 8G of RAM is plenty for a workstation. My main laptop away from home is only on 4G and I seem to manage just fine. My home workstation is 32G but the only time I get even close to that is when I use /tmp to compile a large project.
It's very far off since this is slower and has fewer features than the worst motherboard ($60) and the worst CPU ($50) on the market. Add $30 worth of RAM and you're up to $140.
It's also the first usable workstation for a novel open-source architecture. It's not as fast but that's a feature which, in my opinion, makes the price parity reasonable. Progress is gradual.
A number of companies have asked for popcount to NOT be included in the base spec for B (certainly Zbb for embedded), because of the expense of implementing it vs the relatively small speedup it givesfor quite specialized use-cases.
Of course popcount will have an opcode allocated and binutils and gcc will (already do) know how to use it if it is present, so anyone who wants/needs it can implement it.
In the Alpha case it was a very late addition, in the last widely shipping version of the chip and IIRC was speculated to be part of some supercomputer/classified use case. ARM has a history of having quirky un-RISCy instructions.
(edit: also it seems that ARM has just cnt.v8 for counting 8-bit lanes in NEON and no 64-bit scalar instruction version, interesting. Being part of NEON also means it's an optional part on ARM)
Late addition is more indicative of value than appearing in first releases. People guess about the base instruction set, but additions happen only in response to high demand.
It's still a core without V or B extensions, and still prohibitively expensive for anyone that doesn't need them.
Useful for those working on risc-v ports, and that's about it.