Announcement

Collapse
No announcement yet.

Western Digital To Open-Source The "SweRV" RISC-V Core In 2019

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by c117152 View Post
    Yeah ok, microcontrollers are computers too, point taken. I keep disregarding them when I think of "computer", how racist of me.

    Leave a comment:


  • c117152
    replied
    Originally posted by starshipeleven View Post
    but not really something you want on a SBC.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by c117152 View Post
    You're assuming a single line of products. Besides, going 28nm means they have room to spare for an MCU and a dedicated DSP.
    Yeah sure it can be improved upon and eventually become something better, with RiscV this can sure happen, if someone takes it and invests in it.

    It's just that I see that what is developed as a microcontroller will usually remain a microcontroller because whoever designed it needs to sell to that type of market.

    There have been forays in the "applications processor" from microcontroller manufacturers in the past and it was still not anywhere near useful for general-purpose computing.

    Like the Atmel/Microchip AT91. It's still designed for very very very embedded usecase, great and all, but not really something you want on a SBC.

    Leave a comment:


  • c117152
    replied
    Originally posted by starshipeleven View Post
    This is a beefy microcontroller, but still a microcontroller, I really doubt Linux can (or should be hacked to) run decently in it.

    You need an OS only if you want to run third party software in a half-safe environment, and a storage controller is NOT a processor where it makes sense to run random code on. It has a single purpose. It is served better by a bare metal firmware.
    You're assuming a single line of products. Besides, going 28nm means they have room to spare for an MCU and a dedicated DSP.

    Leave a comment:


  • ldesnogu
    replied
    Originally posted by pkese View Post

    4.9 CoreMarks/MHZ is an insanely high number for an in-order design.
    For reference: an in-order ARM A53 performs at 2.6 CoreMarks/MHz, while an out-of-order ARM A57 gets 4.03 CoreMarks/MHz.

    It is often that HW manufacturers will multiply their CoreMarks by number of cores. Does anyone know how many cores are there in that chip design?
    If it is a 2-core design, at 2.45 CoreMarks/MHz, that is still a respectable number - with a little bit higher frequency, it is core-for-core comparable to Raspberry PI (although half as many cores).
    According to this slide they seem to really claim that they have 4.9 CoreMark/MHz for a single core.




    That'd make SweRV faster than A15 and not very far from IvyBridge. Do you buy that claim? I don't :-)

    Is CoreMark really used in the embedded space? I remember reviewing the benchmark before it was released (during Cortex-A9 design) and it was just horrible. The feedback I gave was: anyone programming a CRC the way it's done would never be accepted in my team.

    Leave a comment:


  • pkese
    replied
    Originally posted by johanb View Post
    Michael You missed to reference the actual benchmark numbers in WesternDigitals blog!
    > The Western Digital SweRV Core™ EHX1 is a 32-bit, 2-way superscalar, 9 stage pipeline core. With an expected simulation performance of up to 4.9 CoreMarks/Mhz
    4.9 CoreMarks/MHZ is an insanely high number for an in-order design.
    For reference: an in-order ARM A53 performs at 2.6 CoreMarks/MHz, while an out-of-order ARM A57 gets 4.03 CoreMarks/MHz.

    It is often that HW manufacturers will multiply their CoreMarks by number of cores. Does anyone know how many cores are there in that chip design?
    If it is a 2-core design, at 2.45 CoreMarks/MHz, that is still a respectable number - with a little bit higher frequency, it is core-for-core comparable to Raspberry PI (although half as many cores).

    Leave a comment:


  • johanb
    replied
    Michael You missed to reference the actual benchmark numbers in WesternDigitals blog!

    > The Western Digital SweRV Core™ EHX1 is a 32-bit, 2-way superscalar, 9 stage pipeline core. With an expected simulation performance of up to 4.9 CoreMarks/Mhz

    After googling some I found that previous RISC-V chips have:
    - Berkeley BOOM prototype (2015): 3.91 CoreMarks/MHz
    - Freedom U500 (unreleased): 2.75 CoreMark/MHz?
    - Freedom F31 (late 2017): 3.1 CoreMark/Mhz

    So 4.9 CoreMarks/Mhz is an incredible improvement over the Rocket/Boom designs it seems!

    Since it will be up to 1.8Ghz and built on a 28nm process node (same as BOOM) this will easily take the throne as the fastest RISC-V chip ever made. (As far as I know , BOOM was previously the most powerful RISC-V chip ever made, correct me if I'm wrong).

    Leave a comment:


  • ldesnogu
    replied
    Originally posted by starshipeleven View Post
    Read my post: did I say this is the only way? No I did not. There are multiple ways to get there.

    That's not what I said. I said that with an open source CPU you know what the CPU registers and instructions are and therefore you can reverse engineer the firmware.
    We're going nowhere, I think we are agreeing in fact I thought your original point was implying that having a FOSS CPU would help getting a FOSS firmware; what I say is that this is unneeded: all you need is a spec of the SoC.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ldesnogu View Post
    Read again my post: you only need open specs for that.
    Read my post: did I say this is the only way? No I did not. There are multiple ways to get there.

    And last point reverse engineering software doesn't make you magically better understand the CPU than an open spec. Do you need to read the source code of gcc to program in C?
    That's not what I said. I said that with an open source CPU you know what the CPU registers and instructions are and therefore you can reverse engineer the firmware.



    Leave a comment:


  • ldesnogu
    replied
    Originally posted by starshipeleven View Post
    That you know what each register does, for starters. That's already a pretty large difference vs "knowing exactly jackshit" that allows to decompile and reverse engineer the firmware or develop your own.

    Also, you can also run this on a FPGA to develop stuff before trying it on a hard drive controller, if necessary.

    Which is irrelevant because none can fab his own chips anyway.

    But with an opensource CPU you know how the CPU works and you can reverse-engineer the firmware.
    Read again my post: you only need open specs for that. Did AMD have to release the RTL of their GPU for FOSS drivers to exist?

    And also you need specs for all of the SoC not only for the CPU. Did WD say they'd release information about all of the SoC used on SSD?

    And last point reverse engineering software doesn't make you magically better understand the CPU than an open spec. Do you need to read the source code of gcc to program in C?

    The only point I agree with you is that indeed you'd be able to use an FPGA. But again this requires access to the source of all of the SoC. And if you only need to run on the CPU you already can do that with QEMU and rv8.

    Leave a comment:

Working...
X