💾 Archived View for dioskouroi.xyz › thread › 25002448 captured on 2020-11-07 at 00:54:09. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

Western Digital SweRV RISC-V Core

Author: ch_sm

Score: 150

Comments: 57

Date: 2020-11-05 21:54:09

Web Link

________________________________________________________________________________

ohazi wrote at 2020-11-06 02:11:06:

If you're looking to start playing around with a RISC-V that fits on a small FPGA, PicoRV32 [1] is a good option. It's written/maintained by Claire Wolf, who also started the yosys and icestorm open source synthesis projects.

PicoRV32 is particularly neat because it includes an SoC wrapper [2] that allows you to place other hardware / co-processors / peripherals on the same FPGA and talk to them from the CPU via a memory mapped interface.

[1]

https://github.com/cliffordwolf/picorv32

[2]

https://github.com/cliffordwolf/picorv32/tree/master/picosoc

chubs wrote at 2020-11-05 22:51:36:

Some information I found at

https://codasip.com/swerv

:

The SweRV Core™ EH1 is an advanced high-performance core with small footprint, suitable for embedded devices supporting data-intensive applications such as storage controllers, industrial IoT, real-time analytics in surveillance systems, and other smart systems.

SweRV Core EH1:

Architecture: 32-bit, dual superscalar, 9-stage pipeline
    Performance: Up to 4.95 CoreMark/MHz (further gain possible with compiler optimizations)
    Clock speed: Up to 1.8 GHz
    Technology: TSMC 28nm CMOS
    Bus support: AXI, AHB-lite
    Programmable Interrupt Controller
    RISC-V debug support

jlokier wrote at 2020-11-06 13:09:04:

> Bus support: AXI, AHB-lite

That's interesting. AXI is from ARM and I think it's still subject to ARM licensing.

johntb86 wrote at 2020-11-07 03:31:17:

I was surprised by that as well, but here's the term in the AXI license: "(i) where a product created under Clause 1(i) is an integrated circuit which includes a CPU then either: (a) such CPU shall only

be manufactured under licence from ARM; or (b) such CPU is neither substantially compliant with nor marketed as being

compliant with the ARM instruction sets licensed by ARM from time to time;"

So it seems like they might be in the clear.

hajile wrote at 2020-11-06 04:50:51:

I wonder how much money they've saved using RISC-V.

ARM used to license (2013) for 1-10 million up front then 1-2% of the street value of the chip in royalties[0].

A little googling find this presentation on swerve [1] EH2 which says 4.9 coremark/mhz with one core. It's 8 stage, dual core (with SMT) targeting 1.2GHz on 16nm. It seems likely to be between an a35 (wearable) and a55.

With those chips starting at around $10 and around 100m units per year, it's easily 11-30 million per year but including the fact that integrating the arm core is also expensive and requires engineers. That money represents 22-60 full time engineers at $500,000 each. They also have a m4 sized chip too which is another big chunk of money

These big companies stand to save a lot moving to RISC-V.

[0]

https://www.neowin.net/news/arm-reportedly-hiking-licensing-...

[1]

https://riscv.org/wp-content/uploads/2019/12/12.11-14.20a3-B...

tyingq wrote at 2020-11-06 09:45:07:

A fairly good overview of ARM licensee costs, albeit from the other side of the table:

https://www.anandtech.com/show/7112/the-arm-diaries-part-1-h...

ksec wrote at 2020-11-06 08:26:48:

The SweRV Core are embedded Deep inside the HDD controller. And are completely different to the ARM counterpart you are measuring against. So they dont cost $10, they are measured in _cents_.

hajile wrote at 2020-11-06 13:31:44:

As the article I linked states, if not sold directly, "pricing" (for figuring royalties) is according to the street value if they did sell them packaged up and these cores match up somewhere between A35 and A53.

dogma1138 wrote at 2020-11-06 07:19:32:

RISC-V doesn’t come with the patents needed to build a modern high performance CPU.

Building modern CPUs isn’t about the ISA of Intel made the x86 ISA open to all tomorrow you still would need a plethora of patents licensed to ship a CPU without being sued to oblivion.

ldng wrote at 2020-11-06 11:04:48:

Hum, on the other hand patents up to Pentium 4 should have expired, right ? So, you might not be able to have "modern" CPU, depending on your definition of modern, but yet be abble to build specialized CPU with decent performance I suppose.

dogma1138 wrote at 2020-11-06 11:48:24:

You still need modern IP for PCIe, modern memory, flash storage etc.

ldng wrote at 2020-11-06 15:23:54:

Right, did not thought of those. But they will not necessarily apply to a specialized embedded CPU. But, granted, a CPU for PC platform is a different story.

dogma1138 wrote at 2020-11-06 22:53:44:

In many cases including the WD case they do.

hajile wrote at 2020-11-06 13:33:24:

That's true, but I'd imagine a company like Western Digital has those patents and cross licensing agreements.

dogma1138 wrote at 2020-11-06 13:40:57:

They might have some, but licensing from ARM gives you all in one neat package, and I’m not sure how much more economical it is to invest in RISC-V especially if you are smaller than WD.

WD is still pretty darn huge and that is kinda the point, with ARM you can roll out cores cheaply without worrying about needing additional licenses.

Until RISC-V will have an ecosystem of oven ready cores that can be licensed for essentially immediate tape out I’m not seeing it as a major threat to ARM.

The biggest threat so far seems to be that ARM may have to lower its fees even further at least for its embedded cores as there aren’t any RISC-V designs out there that threaten their Application Processor uArch yet.

brucehoult wrote at 2020-11-07 00:03:27:

The HiFive Unmatched board with quad U74 cores is available to order now on Mouser or CrowdSupply, with Mouser saying they'll have stock on Jan 1.

The U74 is very similar to an A55 without NEON.

I suspect SiFive is probably going to put the FU-740 SoC itself on Mouser once they have sufficient supplies to fulfill board orders.

Their U84 core was announced 12 months ago and is A72-equivalent (again excluding NEON). They way these things work there will probably be chips and boards available in another 12 months.

The VIU75 core was also just announced as available for licensing. That's a U74 plus RISC-V Vector extension (more like SVE than NEON).

Obviously ARM has already moved on from the A72 and they're up to A78 now with I think the A76 the latest actually shipping in devices (e.g. Samsung Galaxy S20). But RISC-V is catching up pretty quickly considering that four years ago there was no RISC-V chips shipping at all.

Also A72 to A78 is just incremental improvements, much like Nehalem to Sandy Bridge to SkyLake in x86. Of course the newer ones are better, but there are plenty of people out there still happily using Sandy Bridge.

audunw wrote at 2020-11-06 08:55:39:

Do you have any examples of the kind of patents you would need to license?

I don't anything in the ISA itself is covered by patents anymore. And the basic techniques for making a high performance CPU are getting quite old. Seems like a lot of the techniques used by desktop CPUs being released today have a a lot to do with advanced cache architectures, "AI" branch prediction, virtual memory, hypervisors, etc. A lot of these things will not be so relevant to a special purpose embedded CPU like this.

dogma1138 wrote at 2020-11-06 10:51:35:

Depends on what the embedded CPU is for, especially for more bespoke applications that may require optimization for specific tasks like encryption, networking and compression you’ll likely to hit a patent wall quite quickly.

And in general building a high performance ALU, FPU, a modern MMU with virtualization and I/OMMU support, an efficient instruction decoder and register file are all covered by patents that are still in effect.

Large companies that design their own cores cross license a shit tonne of patents between themselves and for everything else they hold each other at gun point.

AMD and Intel quite likely violate each other’s patents all the time at least those that aren’t covered by the cross licensing agreement they just know that if they go to court neither of them will be able to put a CPU on the shelves for the next 3 decades.

NVIDIA got patent slapped to oblivion when they wanted to emulate x86 on GPUs despite technically having an x86 license at the time (although Intel claimed it didn’t cover what NVIDIA was planning) and the fact that binary translation has been ruled not to infringe on ISA related patents.

In general circumventing patents is expensive and if you don’t have a large enough patent portfolio to be able to plausibly claim how you’ve achieved a certain level of functionality you’ll always be at risk of claims and law suits.

Until there will be a large consortium or industry leaders that are willing to share their patents for free or at an acceptable cost through a (F)RAND license with all members I don’t see RISC-V being a cheap version for anyone but the existing giants that already either license enough patents from others or have enough of their own to be bulletproof.

my123 wrote at 2020-11-06 12:19:38:

Note that even Microsoft got warned by this:

https://newsroom.intel.com/editorials/x86-approaching-40-sti...

for Windows on Arm including x86 backwards compatibility.

However, guess that Microsoft has a big enough patent portfolio for Intel to not go beyond that threat...

dogma1138 wrote at 2020-11-06 13:10:43:

Microsoft and Apple also not in direct competition with Intel, and Intel rather not lose more of their business in a pissing contest so I think it's treating them somewhat differently (tho if you don't protect your patents you kinda open yourself for future violations)

NVIDIA on the other hand was and still is a direct threat to Intel in the datacenter.

jacobush wrote at 2020-11-06 13:31:46:

No, that's trademarks, you need to enforce them.

rwmj wrote at 2020-11-06 11:01:10:

Interesting tidbit in this video:

https://youtu.be/hF3sp-q3Zmk?t=390

about how no existing embedded ARM core did exactly what they wanted, so they had to use two of them. With SweRV they were able to design a single core to do the same.

nickik wrote at 2020-11-06 05:41:03:

Given the amount of investment WD has made into the ecosystem its questionable how much money they have made yet. In the long run they will make a fair amount of money, but the cost of developing all these chips, supporting the open source ecosystem and tooling and so on is not free.

Apparently they were able to take over the SPARC people that were dropped by Oracle.

sanxiyn wrote at 2020-11-06 02:07:13:

Note that this is EH1 version. EH2 is an update of EH1 and an improvement in all aspects.

https://github.com/chipsalliance/Cores-SweRV-EH2

wmf wrote at 2020-11-06 05:37:53:

Is it? It looked to me like EH2 might have lower single-thread performance.

ksec wrote at 2020-11-06 08:29:37:

Or similar from OpenPOWER, I thought people might be interested.

https://github.com/antonblanchard/microwatt

unixhero wrote at 2020-11-05 23:10:59:

Clock speed: Up to 1.8 GHz

So clearly this must be possible to run DooM on.

tyingq wrote at 2020-11-06 00:00:50:

Perhaps. No on-die floating point, though.

mrbungie wrote at 2020-11-06 00:35:16:

Doom uses fixed-point arithmetic[1], so no problem.

[1]

https://doomwiki.org/wiki/Fixed_point

leoc wrote at 2020-11-06 02:02:41:

At the time of Doom's release many or most DOS/Windows PCs still didn't have hardware FPUs

https://www.xtof.info/blog/?p=931

I think that using hardware floating-point would have prevented some of the early console releases too (particularly the SNES?)

wk_end wrote at 2020-11-06 07:27:36:

The SNES version was coded from scratch in 65816/Super FX assembly language [1]; how the PC version did things would’ve been neither here nor there.

[1]

https://github.com/RandalLinden/DOOM-FX

- yes, that’s the original code on GitHub, released by the author

MaxBarraclough wrote at 2020-11-06 11:31:41:

HN discussion on the release, 3 months ago:

https://news.ycombinator.com/item?id=23989638

Narishma wrote at 2020-11-06 00:40:26:

Doom doesn't use floating point.

mleonhard wrote at 2020-11-06 04:27:47:

Lots of documentation:

https://github.com/Codasip/SweRV-Support-Package-free

homarp wrote at 2020-11-05 23:19:29:

some more background:

https://www.linkedin.com/pulse/2019-year-risc-v-open-source-...

G4E wrote at 2020-11-05 23:51:42:

Does anyone know in which product they put this chip ?

It would be fun to get it out and repurpose it on a custom board !

tverbeure wrote at 2020-11-06 05:27:33:

I wrote about a deep dive blog post about the SweRV EH1 when it was first introduced.

Check out the slides in the "Various" section:

https://tomverbeure.github.io/2019/03/13/SweRV.html#various

It shows how 2 SweRVs are used inside a NAND flash controller.

duskwuff wrote at 2020-11-06 00:17:25:

It's probably going to be deeply embedded in their hard disk controllers. Nothing you'd be able to easily reuse.

userbinator wrote at 2020-11-06 00:31:36:

People still try... and achieve:

https://spritesmods.com/?art=hddhack

dylan604 wrote at 2020-11-06 02:47:50:

I've heard tales of persistent hacks from nation state type attackers by putting the malicious code onto certain chips like the various ROMs have, but this is the first time I've read this level of detail about someone's attempt that was not funded by a nation state. However, can these be delivered remotely without physical access to the hardware? My threat model is not one where I'm concerned about a physical attack, but because of INTERNET, I am curious about software only hack possibilities.

brokenmachine wrote at 2020-11-06 05:12:23:

From page 6 of that (awesome!) article: _After some messing around and guessing VSC parameters, fwtool could all of a sudden also read and write the flash of a HD attached to the PC it's run on._

So a remote attacker who already had root access to run fwtool could do it.

duskwuff wrote at 2020-11-06 18:15:55:

> However, can these be delivered remotely without physical access to the hardware?

Yes, most devices (including hard drives) can have their firmware updated from the host computer. Some newer devices support some form of firmware signing, making it more difficult for a malicious firmware to be installed, but they're in the minority -- most firmware update mechanisms are insecure.

numpad0 wrote at 2020-11-06 05:14:41:

Is your question like "is there any device that can be reflashed from running OS without user intervention?"

...yeah, a lot...? Over SATA link? I don't know, over NVMe? maybe, over regular PCIe? a lot, over USB? a lot...

dylan604 wrote at 2020-11-06 16:06:22:

I know that Thunderbolt with its direct access to PCIe has been the thought of scary scenarios. Again, all of the attack vectors you've mentioned require physical access, and we all know that it's game over once the attacker has physical access. I'm talking about drive by installs of malicious websites or that downloaded copy of bejeweled that someone's mom downloaded.

numpad0 wrote at 2020-11-06 16:52:13:

Could you clarify "physical access"? Of course the victim device has to be alive on the target machine that runs said hypothetical bejeweled.

Adversaries won't have to physically plug the device in, though, because there are plenty such potentially exploitable devices that are readily available on average computers(desktop or laptop). BIOS ROM chips, gaming RGB LED controllers, motion sensors, power management microcontrollers, internal Wi-Fi or Bluetooth chips, potentially some HDMI monitors, SSDs, HDDs, potentially Blu-ray drives, certain USB drives, gaming mice, GPUs, high end network controllers, BMCs for remote server management... Today even a microSD card runs some sort of software.

I think you'd have to go back to at least Pentium 2 or III days, further back if you want a laptop, to be confident that there is _no_ standalone microcontrollers that can be hacked from OS by adversaries, and that any reprogramming features in components are/can be fully disabled in hardware or at least by OS. Microcontrollers were usually overkill for simple management tasks back in those days, and ROMs either had hardware write enable pins or external reprogramming voltage supply required to do it.

ComputerGuru wrote at 2020-11-06 02:21:58:

Such a humbling read. Thank you for sharing, I somehow did not come across this when it was previously making the rounds.

pkaye wrote at 2020-11-06 00:31:00:

Would this fit on an FPGA?

tverbeure wrote at 2020-11-06 06:27:00:

It does, but it's not a great solution:

https://tomverbeure.github.io/2019/03/13/SweRV.html#swerv-fo...

.

vxNsr wrote at 2020-11-05 23:41:45:

As cool as this, WD should be blocklisted just because of their unfriendly practices around product naming and flouting conventions.

reitzensteinm wrote at 2020-11-06 00:02:47:

It pissed me off too, but if that's the threshold for a blacklist it's hard to think of a tech company that would make the cut.

neolog wrote at 2020-11-06 00:50:33:

What does this refer to?

meragrin_ wrote at 2020-11-06 01:26:11:

They were selling NAS drives using shingled magnetic recording(SMR) without providing any hint the drives were SMR. There are a number of NAS setups which SMR drives cannot be used in.

squarefoot wrote at 2020-11-06 01:47:17:

From what I know, plain WD Red drives are the only SMR drives produced by WD, and are the newest development; they just switched the names so that the old plain CMR WD Red disks became WD Red Plus.

Therefore WD Red Plus and the faster WD Red Pro models should be 100% safe, while plain WD Red ones, especially if bought less than a couple years ago are not. Corrections welcome of course.

tremon wrote at 2020-11-06 09:25:18:

That's only after public outcry. When first introduced, WD Red used CMR for some capacities and SMR for other capacities, like Toshiba does as well for e.g. the S300 line [0].

At least they're now documenting the technology they're using [1].

[0]

https://www.toshiba-storage.com/products/s300-surveillance-h...

[1]

https://www.westerndigital.com/products/internal-drives/wd-r...

sigjuice wrote at 2020-11-06 05:40:50:

Their rebranding and name switching is not very reassuring to me. I ordered two Red Plus drives (WD101EFAX) last month, but the drives I got are labeled "Red". I remember seeing some fine print (maybe on their website or in the box I got) which said "you might get drives that look like they are Red, but we promise they totally are Red Plus ...". That said, the drives are working fine AFAICT and I honestly don't know enough about hard drives to tell the difference.

meragrin_ wrote at 2020-11-06 14:40:15:

The larger ones like the 10TB ones did not have SMR versions so you should not worry about having an SMR drive.

numpad0 wrote at 2020-11-06 05:46:52:

Not _any_ hint, it was known among 5ch forum dwellers since they came out. Those disks had platter counts, disk capacities and other specs that do not coincide with CMR configurations according to them.

andoriyu wrote at 2020-11-06 01:37:50:

Also, not showing real rotation speeds and calling what they show "5400 class" which wasn't 5400 at all.