back to article Seagate says it's designed two of its own RISC-V CPU cores – and they'll do more than just control storage drives

Seagate says it has, after several years of effort, designed two custom RISC-V processor cores for what seems a range of functions including computational storage. The disk drive maker told us one of the homegrown CPUs is focused on high performance, and the other is optimized for area, ie: it's less powerful though smaller …

  1. Doctor Syntax Silver badge

    "may signal a coming surge in RISC-V processor shipments"

    May also signal concerns about the future ownership of Arm.

    1. Anonymous Coward
      Anonymous Coward

      Apple moved from (6502 to) 68k to PowerPc to x86 to ARM while migrating software via emulation layers so why could't they move to RiscV (which is a much smaller change than any previous change) and effectiviely take the entire CPU "In house" (no need for an architecture licences ... actually, they probably have no need for RiscV and could probably design their own architecture if they wanted). So, why should they pay ARM any "significant" license/royalty fees as they've got very little dependency on ARM as their ecosystem is targetting the architecuter they define which just happens to be moving to ARM at the moment.

      1. MJB7

        Re: Apple

        On the scale that Apple works at, the licensing costs for Arm may not be that significant compared to the costs of switching to RiscV. Apple are probably using RiscV in their commercial discussions with Arm already.

        1. Julz

          Re: Apple

          Apple have a complicated relationship with ARM. I doubt if they pay the same royalty fees that other might.

        2. Elledan

          Re: Apple

          Apple is one of the founding members of ARM (back in the 1980s). They hold a perpetual license to the ARM ISA and related technologies as a result and do not pay license costs to ARM, as, in a sense, they are ARM.

    2. StrangerHereMyself Silver badge

      I believe that no one really believes that things will remain honky dory if Nvidia takes over ARM.

  2. Anonymous Coward
    Anonymous Coward

    So a billion CPU's a year .... even if ARM only get 1c per CPU roylaties then you can probably afford to run a decent CPU design team for less than that and know that all the software tool sife is availbale "for free" (ol, you can probably afford to put a bit towards this as well - but you don't have to) ... not looking good got ARM (or is that ARMnVidia)

    N.b. 20-25 years ago when ARM were the "up and coming architecture" other processor architectures had to deal with the "its just a processor and ARM looks cheap - plus our new grads used it at Uni" argument and mostly lost ... looks like the boot is on the other foot now!

    1. rcxb Silver badge

      In that ARM license you're paying for the patents they've taken out over the years, as well. You've got to be careful not to implement something ARM patented in your RISC-V chip or you'll really pay for it.

      1. diodesign (Written by Reg staff) Silver badge


        FWIW I asked the RISC-V Int'l directors about patents, and they were pretty sure anything they spec out that Arm could claim ownership of could be traced back to pre-Arm days, or would be entirely new and novel.

        I think there's going to be a patent royal rumble at some point. One side - and not just Arm or a RISC-V member - is going to crack and it's going to kick off, and we'll find out that once again IBM has the patent on adding 4 to the program counter each cycle.


      2. Anonymous Coward
        Anonymous Coward

        Patents are a problem for everything...

        ...but at least unlikely to apply to the Risc-V instruction set.

        Of course if you want to connect your Risc-V core to some RAM, you'll need to license the RAM controller. Or if you want HDMI. Or play video. Or a GPU that is vaguely compatible with existing programs.

        You can probably figure out a power supply, though.

  3. tcmonkey

    Well, hopefully this means they’ll be putting a bit more effort into their control logic and software going forwards. Anyone who has ever done any data recovery on them will tell you that their current stuff appears to have been shat out rather than ‘developed’.

  4. Loud Speaker

    Embedded SQL?

    When SCSI first replaced SASI (about 40 years ago) I proposed disk drives with embedded SQL processors, so, instead of looking up your info via a file system, you searched for it in a database. In other words, instead of telling the drive where to look for the data, you tell it what you want, and ask it to go and find it.

    Of course, this costs computing power, but if you are getting the computing power for the price of 1/2 teaspoon-full of sand (incremental cost of Risc-V) then why not use it to off load processing from your (Beowulf cluster of) mainstream CPUs? Postgresql is pretty cheap these days, as it does not need to fund any AC75 yachts. (If you need any good indexing algorithms for text, PM me - I want an AC75 for myself).

    (At the time I was proposing to use an array of pipelines of Transputers, but Mrs Thatcher quietly took the Transputer round the back of the shed and shot it).

    1. John Sturdy

      Re: Embedded SQL?

      Another project / product in this area was CAFS, the Content Addressable File Store, which searched directly in the drive. I knew someone who had worked on it, who said it used a microcoded processor to do regexp searches as the data passed the heads --- none of this cumbersome "reading it into memory first" stuff.

      1. Julz

        Re: Embedded SQL?

        I worked on and with CAFS and it had its place and I think similar systems would have their place today.

        The main advantage was freeing up your expensive mainframe from the laborious, time consuming and CPU intensive task of searching though gobbets (technical term) of data finding the nuggets that where then passed on for further processing. CAFS searches were loaded into the disc controllers and retrieval kicked off. Only hit records were returned. A great boon if the ratio of data to be searched to the number of hit records was large.

        It's other main advantage was that it could be loaded with what amounted to free text searches of arbitrary fields. Thus, way back in the day, what amounted to unstructured big data, could be searched efficiently for matches against whatever criteria your big data analystsDBAs or even end users wanted.

        The closer to the data you do the filtering the less the data has to move about and is thus more efficient the process is. That is assuming you are keeping the rest of the system busy doing useful work and not just heating up the atmosphere.

    2. juice

      Re: Embedded SQL?

      > When SCSI first replaced SASI (about 40 years ago) I proposed disk drives with embedded SQL processors, so, instead of looking up your info via a file system, you searched for it in a database

      Back then, any such solution would have been proprietary - as I recall, at one point Oracle even offered it's own file-system for people wanting to maximise performance.

      But either way, I'm really not sure about the benefit of this approach. Because fundamentally, any system advanced enough to perform complex activities on your data will be complex in and of itself.

      E.g. a SQL "processor" would need code to parse and process the SQL language. It would then need memory, so it can store the data while processing it. And so on, until what you effectively end up with

      a full blown server in it's own right.

      And that's before you consider how many extra layers of abstraction we have these days. E.g. if a company has any sense, any sensitive data will be encrypted at rest. And/or the fun which lies in debugging issues when you have a black-box design like this.

      Arguably, that's the sort of thing which services like Elasticsearch are trying to address - in an era where processor cycles are cheap and disk space is cheaper, it makes sense to build a secondary platform containing denormalised data which you can quickly search before going back to your main datastore (assuming you can't just pull what's needed from the secondary platform).

      But embedded processors at the disk hardware level? That's at completely the wrong layer.

    3. Cynic_999

      Re: Embedded SQL?

      No, IMO the drive is not the place to do content searching. The reason being that either the entire drive would have to be seached for every query, which would take far too much time, or the drive would only work with a very specific database format - and even then would have to have a large amount of RAM to store the hashing tables and caches. This would be too inflexible for use as a general purpose HDD, and in any case not be much cheaper, smaller or use less power than a conventional HDD attached to a separate CPU system or full-fledged server PC.

      Even making a drive that has a built-in file system so that it accepts file-based commands directly is not a particularly good idea IMO, because it greatly decreases the HDDs flexibility while not achieving much advantage (if anything) to whatever system it is attached to.

    4. Anonymous Coward
      Anonymous Coward

      Re: Embedded SQL?

      I once asked a Microsoft guy what happened to the database filesystem that was meant to replace NTFS. He said "reality happened".

      Filesystems are not databases, even if parts look superficially similar.

      1. FIA Silver badge

        Re: Embedded SQL?

        I once asked a Microsoft guy what happened to the database filesystem that was meant to replace NTFS. He said "reality happened".

        That's quite succint considering it took them four attempts to realise this. (OFS, the first, is available in some betas of NT according to youtube). As for the rest.... I think there might've been a vista beta with WinFS in but who knows???

        Filesystems are not databases, even if parts look superficially similar.

        You know this.... I know this..... (I mean FOUR attempts..... I'd still not try it now and computers are much quicker.....)

        Mind you, the Be File System had metadata level indexing, which was supposed to be quite good, but still, that's a far cry for trying to fit a DB in there.

  5. rcxb Silver badge

    Who cares about shipments?

    it shipped about a billion CPU cores last year in its storage products, this development may signal a coming surge in RISC-V processor shipments

    And does that matter to anyone? The fabs likely don't care the architecture. If it's a fairly a small number of designs, it doesn't even suggest a large number of RISC-V jobs in the job market, either.

    1. diodesign (Written by Reg staff) Silver badge

      "And does that matter to anyone?"

      Uh yeah, it matters a lot. It's a validation of a design, for one thing. You're right that the fabs -- and by that, we mean TSMC, etc -- don't care about the architecture. That's not their job.

      But people further up the chain considering using the architecture will think it matters. 'Can we trust that this tech works?' 'Well, Seagate just put XYZm into production.'


      1. sw guy

        Re: "And does that matter to anyone?"

        I am not quite sure one can say this is not the job of TSMC at all.

        TMSC has hard-cells for CPU available (at cost) for their customer, hasn't it ?

  6. Anonymous Coward
    Anonymous Coward

    Interesting stuff, but I'm not really sure what the benefit is to the end-user.

    I mean, they're talking like you could offload certain computational tasks to your storage device much like you can do with GPUs now....but given the...err...temporary nature of storage devices in large clusters what happens if a drive fails but it's currently running a task the system needs?

    I suppose the main advantage would be the ability to handle tasks like drive-level encryption entirely in hardware rather than relying on the OS to do it.

    1. StrangerHereMyself Silver badge

      It means products will become even cheaper or will have even more computing power at the same price point.

      ARM processors are already dirt-cheap (you can get a powerful MCU for just a few bucks) but they will become even cheaper (less than a dollar each) if RISC-V takes off.

      MCU's arre already so cheap that I wonder if it's even useful to make them any cheaper. Anyone can slap something together using today's MCU's at a price that's very wallet friendly. By making it any cheaper it will simply become a throwaway.

      1. Anonymous Coward
        Anonymous Coward

        cheaper than something simpler!

        When I worked at ARM (a few years ago) there were rumours in-house that the cheapest M0 cores were cheaper than 555 timers.

        1. StrangerHereMyself Silver badge

          Re: cheaper than something simpler!

          And M0 cores are actually quite powerful, at least 10 x faster than 8-bit AVR parts.

          In fact some of these new parts are *so* powerful I'm actually at a loss what to do with all that horsepower. The RISC-V MCU used in the SiFive SBC is 40 times (!) faster than an AVR 8-bit MCU.

    2. eldakka Silver badge

      The offloading of tasks they are talking about aren't general purpose system tasks, but tasks related to the data on the device where if the device failed the data would be gone, so it wouldn't matter the task running on the device fails/can't complete.

      Examples beyond what you already mentioned like drive-level encryption (which, btw already exists, a self-encrypting drive, of which there are many examples of HDDs and SSDs that already have the onboard processing to do that), could be things like offloading a 'find' command to the device, or data processing tasks such as what scientific data gathering systems would like. Massive sensors like radiotelescope arrays (e.g. the SKA) generate peta-bytes a day of data. You could have some initial filtering of that data occur on the drives, so as the raw data is streamed to the drive for storage, some filters could be applied in this offloaded processor that say, can detect and discard 'junk' raw data so it doesn't have to write it to disk, and doesn't have to be processed by the supercomputer doing more detailed analysis as the on-drive filtering eliminated it already.

      1. Charles 9

        Remember back in the day that Commodore floppy drives actually had their own CPUs and OS built into them, mostly because the data transfer rate on the serial line wasn't so great?

      2. Cynic_999

        Such specialist filtering of data would surely be better achieved by a board running bespoke software placed in-line with the drive, so that it is tailor-made to filter and/or pre-process the specific data being dealt with.

    3. Cynic_999

      Drive-level encryption has been around for decades. Many (most?) SSDs are also SEDs, although few people seem to use the feature.

      But it sounds to me that the main reason for the hardware change is to allow more precise (and perhaps faster) servo control, which will mean more storage in the same area of disk, and maybe faster seek times. These are things that cannot be done in an external CPU.

  7. StrangerHereMyself Silver badge

    Startling growth

    I'm amazed how fast the usage of RISC-V is growing. I'm certain the sale of ARM has accelerated this and will continue to accelerate it even further in the near term. Currently there are almost weekly reveals of new RISC-V designs, both in the U.S. and China. (I haven't seen many European companies jumping on board).

    I'm interested how fast the tool chain, which is said to be one of ARM's distinguishing points, is able to catch up.

    1. Elledan

      Re: Startling growth

      China's focus seems to be on x86 (via VIA's license) and MIPS (Loongson). As part of their 'China 2025' initiative, both have received massive government support.

      You can even buy a Loongsoon MIPS-based laptop in China, e.g.:

  8. David Pearce

    No, this is the decline of x86

    Both ARM and RISC-V are racing away because the world is finally moving on from everything being a x86 PC running Windows. RISC-V is catching up with ARM because of the politics

    1. StrangerHereMyself Silver badge

      Re: No, this is the decline of x86

      The big iron and PC market will only switch to RISC-V or ARM if one of them can break the 5Ghz barrier.

      The cost of switching platforms and architectures is huge and people and companies will not want to swallow that cost unless there's a clear advantage.

      1. Charles 9

        Re: No, this is the decline of x86

        But doesn't physics get in the way of that, given Intel probably would've hit 5GHz long ago otherwise?

        1. StrangerHereMyself Silver badge

          Re: No, this is the decline of x86

          Intel has already broken the 5Ghz barrier.

          But let me rephrase that: they'll have to be markedly faster at similar clock rates that Intel and AMD currently obtain.

      2. Porco Rosso

        Re: No, this is the decline of x86

        Micro Magic 64-bit RISC-V core broke that 5Ghz barrier I think

      3. Anonymous Coward
        Anonymous Coward

        Re: No, this is the decline of x86

        5Ghz is a physics problem, not particularly related to the instruction set.

        At the end of the day, CPUs switch transistors. Instruction sets are just a big lookup table to control that process; part a chain of encodings starting in the middle of your GCC/LLVM compiler...

  9. Anonymous Coward
    Anonymous Coward

    ...and they'll do more than just control storage drives...

    Yes... They'll quietly connect to the information superhighway and your data will be bussed off to China.

  10. Jamie Jones Silver badge

    But can they read mail?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like