SiFive to Debut RISC-V PC for Developers Based on Freedom U740 Next-Gen SoC | Hacker News Reader

SiFive to Debut RISC-V PC for Developers Based on Freedom U740 Next-Gen SoC

cnx-software.com

170 pointsguerby59 comments

Bring it on. If Arm is the future of desktop computing, it'll need a competitor.

Indeed, plus a viable competitor is the best way to ensure Nvidia is a reasonable steward of the Arm ecosystem.

The likelihood of ARM sailing off into the distance and x86 disappearing is very slim. It's worth keeping in mind that they have more in common than you might think (i.e. RISC and CISC don't mean a huge amount any more when the old x86 instructions aren't used any more and ARM had/has a JavaScript instruction)

So if RISC-V adopts WASM would that give it an interesting edge? I'm not a hardware guy, all software, but definitely would love to see a little more diversity in consumer grade hardware.

You could standardize a WASM translator into any ISA (or a direct implementation hypothetically), but it wouldn't be particularly useful because WASM is designed to be nice (safe) to be run in the browser in a JIT environment.

If you want diversity, and an introduction to truly Alien CPU designs I recommend taking a look at the Mill.

x86 has a quite variable instruction size, up to 15 bytes. So an x86 decoder will be more complicated than an ARM or RISC-V decoder. I'm pretty sure that means that designing performant IP is more difficult engineering-wise for x86.

No doubt, but it is already worked out.

And it turns out to take up a remarkably small area of the die. So, unless it actually slows down execution, it is a small tax that is overwhelmed by benefits of volume production.

Sorry for going off topic, but your comment confuses me. Doesn't "sail off into the distance" mean to disappear? But you're saying the opposite in your comment?

My reasonibg being that when a ship sails off into the distance it disappears from view.

You read it right.

I think they are saying it is unlikely ARM or x86 disappear, and that these instruction sets share some unexpected commonalities. They are not otherwise comparing/contrasting x86 and ARM, they are basically evaluating if either one seems likely to disappear and answering in their opinion: “no”.

As in sailing off leaving x86 behind

"ARM has a Javascript instruction" is just misinformed.

They have always had the FCVTZS instruction which converts a floating point number to an integer (just as every instruction set has). If the floating point number is too large to fit in an integer then the bottom 32 bits are returned.

The new(ish) FJCVTZS does exactly the same operation except that if the floating point number it too large then the largest integer is always returned.

The implementation complexity difference is just about zero. It just so happens that the new instruction fits what JavaScript wants while the old one fits what C wants.

There is certainly nothing non-RISC about FJCVTZS. It's a perfectly simple instruction.

Speaking of competition, I was reading the Mill news board and apparently they were planning on taking a step up this summer but COVID meant they couldn't do it. (But they are still ticking along)

Sadly the Mill is by no means an open ISA, mostly because of all the patents they are filing.

In the current legal environment exported by the US, it might be better to have licensed patented technology. Otherwise one leaves opportunity for trolls to patent and sue companies in that space.

Isn't this the point of the Open Innovation Network?

I wonder to what extent the digital logic design is open source. The RISC-V core ought to be, but what about the memory controller or PCIE root complex, (or USB3)? Those parts are also very important.

Just because it's RISC-V doesn't mean it's open source. RISC-V is an open architecture so anyone can make an implementation but those implementations can be closed source. SiFive have released some open source stuff (https://github.com/sifive/freedom) but the majority of their work is closed source IP. In a way they're quite similar to arm.

Just like ARM, the only thing standard is the core and there is massive (and almost always publicly undocumented) diversity of everything else.

Not just like ARM. You don't need a license to implement a RISC-V compatible machine. IIUC, you only need to pass a compliance test to brand your machine RISC-V and use the trademark.

There's not just one RISC-V core, one of the great things is that there are many, of varying complexity and performance. Some are very open source some are not.

There's already GCC and clang support, linux is here too.

GCC doesn't have support for this system's vector unit in the development source as far as I can see. Does LLVM?

The vector extension is still in draft and still changing. We don't want to add support that we will have to remove later if the proposal changes again. But we have support in the rvv-intrinsic branch at github.com/riscv/riscv-gnu-toolchain. There is also LLVM work, they have different rules for development, so are handling this differently.

Thanks. That's rather what I'd expect, but I was surprised at hardware being announced with (some version of) the vector extension and wondered what support there would be for it. Is it reasonable to ask what you might expect in terms of changes if you started playing with an initial implementation, or is it still wide open? (Assuming the right Jim!)

The vector extension is getting close to being formally submitted, so things should settle down. There was a major compatibility break a few weeks ago, but I'm hoping that was the last one. We won't know for sure until it is approved.

Vendors advertising vector support will have to maintain their own toolchains if they implement drafts. Most vector support is in IP cores, and they can be changed to follow the draft. There is no problem until someone makes an ASIC. Unfortunately Alibaba already did that and they are going to have lots of problems as they are incompatible with everyone else. But most everyone else is waiting for the official vector extension before making ASICs.

Press release:

https://www.businesswire.com/news/home/20200914005108/en/SiF...

If this is anywhere reasonably price and has open firmware, I'm in.

Sigh. Still without the Bitmanip instructions.

Meaning, no popcount :-P

That spec is just a draft, and still undergoing revision. Its close in spirit to a Scheme RFI (request for implementation). Until the consortium ratifies it (ie, members state their intention to implement it), its just a wishlist. A well-reasoned wishlist, but a wishlist just the same.

Exactly the point: no popcount.

It is just hard to imagine the thought process that would leave something as important as popcount to such a dodgy and long-delayed prospect; hard to imagine omitting it from the core instruction set, so that it is only ever implemented, if ever, in the most distended and expensive chips.

I think RISC-V isn't really targeting general-purpose machines. They are targeting special-purpose machines. Think Google TPU built from a RISC-V scalar unit + custom tensor unit. 64-bit flash controller without a multiplier or MMU, but with specialized instructions to accelerate error correction. Something to manage the DDR training at startup. Embedded security widgets. Things like that.

This is a development machine announcement for the companies who are building such custom hardware.

The sort of things being targetted by one effort are listed at https://shakti.org.in/processors.html whether or not that has anything to do with popcount. This SiFive one seems interesting for having the vector extension, though that hadn't been finalized the last I knew.

The Pentium didn't include a popcount opcode. One wonders how such a crippled chip ever made it in the world.

Everything has it now. The NSA demanded that any machine they use have it, going back to the '60s. For reasons.

It isn't as if RISC-V implementors are precluded from extending or implementing the bitmanip spec.

Yet, and this is the point: they haven't.

Lots of them have. Just not standard.

There are a number of companies asking that popcount not be included in the standard Bitmanip extension, but be optional, because it is expensive to implement.

Yet, far less expensive to implement than to code around the lack of.

This is all the more reason to get it into the core.

Have not seen any RISC-V offering from the Chinese yet. I wonder if SiFive will have any competition.

Here you go: M5Stack tiny computer with a camera, LCD and RISC-V AI-capable Chinese chip (Kendryte K210). Available on Digikey for $26.50: https://www.digikey.com/products/en?keywords=K027&v=2221

Please note that it has a non-working MMU and is limited to 8 MB of DRAM. This is not the SBC you were looking for.

The MMU works fine, it's just poorly-documented and turns out to implement the incompatible draft-1.9.1 spec not the ratified and standard-going-forward 1.10 spec.

This is not Linux-capable though. The choices are FreeRTOS and bare metal. The chip is pretty unbelievable at that price though. You get a lot of functionality for $9. And it works - I have it on my desk.

Yes, it's the beauty of RISC-V: eventually, it's going to cover all the niches. From RFID energy-gathering chips up to desktop / datacenter CPUs.

Right now, its use is still very fragmentary, but Kendryte K210 chip shows that Chinese chip designers already got some real experience with RISC-V, and it's safe to bet it will be more chips with RISC-V coming from China every year.

For some value of "capable": https://github.com/torvalds/linux/blob/master/arch/riscv/con...

Last time I looked at it (few months ago) the K210 had absolutely awful documentation (datasheet was basically just a pinout) in English and Chinese.

Not awful but for a high margin product I'd just use a US arm chip (e.g. LPCxx).

K210 has a decent AI accelerator (0.8 TFlops by their specs) that can run TFLite models at 300 mW). LCPxx are not even remotely capable of that.

True but I was looking at just for being RISC-V rather than the coprocessor

AllWinner are doing a big run (50 million rumoured) of RISC-V chips through TSMC.

Do you have a source for this? I'd love to know what node they're using. I'm guessing no better than 12nm, but who knows?

At some level... does it matter? The BCM2837 (used in the RPi 3), is 40nm if https://www.raspberrypi.org/forums/viewtopic.php?t=137991 is to be believed; more advanced fabbing is good if you wanna go head-to-head with cutting edge ARM or even x86, but for a lot of stuff you don't need to be that good.

It will not be anything high performance.

http://www.semimedia.cc/?p=7803

T-Head's largest chip has 16 cores when built in 12nm. No idea what configuration AllWinner will be using, but the design itself is not a minnow.

Seems like they'll go for something low power and low performance at first. (from some chatter I've overheard on linux-sunxi)

Which company designed the riscv cores in the soc?

Ping-tou Ge aka T-Head Semiconductor, part of Alibaba.

Have you looked? Not seeing means you should probably turn on the light switch. You are in a dark room.

Sounds like Alibaba might be working on something:

https://www.nextplatform.com/2020/08/21/alibaba-on-the-bleed...

Alibaba have presented their Xuantie910 RISC-V processor, one month ago at Hot Chips.

It is by far the RISC-V CPU with the highest performance ever designed.

Nevertheless, to reach that performance, they had to add a custom instruction set extension with indexed addressing modes, as a workaround for the greatest defect of the RISC-V ISA, its incomplete set of addressing modes.

Reply on news.ycombinator.com