
Verilog sources for Western Digital's open source RISC-V core - obl
https://github.com/westerndigitalcorporation/swerv_eh1
======
m0zg
First of all, kudos to WD. This makes me feel good about spending $1500 on
their spinning drives just last week.

But on a more practical note, what kind of board and toolchain does one need
to get this going on an FPGA? Is there a readme somewhere that would walk one
through the process?

~~~
FPGAhacker
Depends on what you want to do I guess.

You'd need a SoC variety of FPGA with a memory controller as I didn't see one
in this code base. Putting this in an FPGA seems feasible.

But I see some challenges. It looks like it's a Harvard-architecture core.
That means separate buses for data and instructions, which is not common
outside of embedded or specialized systems. I'm sure you can setup GCC to work
with this, but it would be a project.

You could build (or find) a memory controller that can multiplex separate
instruction and data buses to a single memory space... decide data will be in
memory range A and instructions in memory range B, and inform the linker where
to put code and data.

I'd probably start by downloading whatever free versions of the fpga tools the
vender's offer and see if I can synthesize the code with any of the targets
and how well it fit. (assuming someone else hasn't posted that info already).
If it isn't going to fit in anything supported by the free version of tools, I
probably wouldn't go any further with it myself.

Assuming that it did fit, I would switch gears and would build a simulation
testbench, and start tinkering to see how it worked as compared to the docs.
If it really is strictly harvard, I'd build a bridge to the FPGA's memory
controller that could map two buses to a single memory space. If I got that
far I'd start working setting up a compiler and linker to map out code and
data partitions to that memory space.

At this point you might be ready to build all this and load the FPGA, but you
have no peripherals (like ethernet or a vga). I'd consider slaving it to a
raspberry pi or something like that. I saw a debug module in the github repo,
so that might be a good thing to expose to the raspberry pi. Or pick a simple
bus like i2c and use that to get some visibility from the r-pi into the risc-v
state and bridge over to the ram.

\---

Another direction you could take would be to get something like a
snickerdoodle. I believe it can boot linux with the arm core in the FPGA, and
it has the peripherals you need like ethernet(wifi) and access to an SD card.
So the direction I would take there is trying to supplant the ARM core with
the RISC-V. So the effort there would be to disable the ARM core, which ought
to be straight forward, and build a wrapper around the RISC-V core to be able
to talk to the peripherals in place of the ARM.

Given that it's an ARM core, I'm sure all the internal busing is AMBA
(AHB/APB/AXI), so it's probably pretty reasonable to try this.

~~~
dbcurtis
> I'm sure you can setup GCC to work with this, but it would be a project.

FWIW AVR is not only Harvard, but code memory addresses point to 16-bit words,
and data pointers to bytes. Yet, gcc works great (mostly). It is mainly a
matter of whipping up a good linker script and directing code and data to the
appropriate sections. Not particularly hard, although Harvardness does leak
into your C code, mostly when taking pointers to functions or literal sections
stored in flash.

*mostly — gcc long ago stopped taking optimization for code size seriously. Unfortunate for uCtlr users, as for small processors like the AVR optimization for size is pretty much also optimization for speed. Gcc has had some pretty serious code-size regressions in the past — but mostly not noticed by people not trying to shoehorn code into a tiny flash space.

~~~
haberman
It's surprising to me that the RISC-V ISA specification is loose enough that a
core could be considered RISC-V-compliant and yet also need a linker script to
accommodate its peculiarities.

~~~
dbcurtis
?? linker scripts are about the layout of the executable. The OS (if there is
one) is the driver of that. ISA spec is an orthogonal concept.

~~~
haberman
On x86-64, the page tables control memory access permissions (rwx). The layout
and semantics of these page tables are defined by the ISA and work the same on
any processor. You wouldn't need to lay out your binary differently on Intel
vs. AMD, for example.

It sounds like AVR, by contrast, has some parts of the address space that are
(x) only and others that are (rw) only, even though other RISC-V processors
don't have this restriction. That seems odd to me.

Maybe it's not as odd if you think of memory as a device that is mapped into
your address space. ROM could be mapped into an x86-64 address space and be
read-only -- even if the page table said it was writable it would probably
throw some kind of hardware exception if you tried to actually write it.

~~~
Dylan16807
(AVR isn't RISC-V)

Having page tables at all is completely optional on RISC-V. This is a chip
with no MMU.

------
dooglius
They have an open-source software simulator for this as well:
[https://github.com/westerndigitalcorporation/swerv-
ISS](https://github.com/westerndigitalcorporation/swerv-ISS)

I'm curious how the performance compares to other open-source cores

~~~
thesz
From cursory glance they have operand read bypass and branch prediction.
Operand read bypass speeds things up considerably (factor is 1/N, where N is
pipeline length) and the presence of branch prediction hints at speculative
execution.

There are two ALUs.

It seems like highly performant core.

~~~
bogomipz
>"From cursory glance they have operand read bypass and branch prediction."

I'm not familiar with "operand read bypass", is this the same thing as
"operand forwarding"? Is this a pipeline optimization? Might you have any link
you could share on this?

~~~
thesz
It is the same thing. Just different name.

------
ksec
How does it compare to BOOM [1], both RISC-V and both open source.

[1] [https://github.com/riscv-boom/riscv-boom](https://github.com/riscv-
boom/riscv-boom)

Edit: Not sure why I am getting downvoted, isn't this a valid question?

~~~
garmaine
Because you’re comparing a workstation class out-of-order CPU design to a
teeny tiny embedded chip lacking an FPU or even a unified code/data cache.
It’s like saying “how does the Intel Atom compare against the AMD Ryzen
Threadripper core?”

~~~
TomVDB
Compared to the most other RV32 soft core implementations, this one is far
from being teeny tiny!

------
quinta1k
It would be their dream come true if the hw oss community (very small) takes
this up and develops it into something huge like for sw projects. There is so
much manpower needed to develop these kinds of things - what better way than
oss.

However, too little, too late, ee industry. An entire generation of top tier
college students have pretty much skipped ee.

~~~
writepub
Lots of unsubstantiated claims here. WD doesn't need the OSS community, the
community won't make or break the project. They're a 'nice to have' at best.
Remember, if this really means savings of $X (that goes to ARM ??) per unit of
storage shipped, given their volumes, they'll gladly fund this to the finish
line. Claiming WD _needs_ the OSS community is like claiming chrome/Google
needs the community. Sure, the community contributions are valuable, but the
core funding and heavy lifting is always in-home.

As for a whole generation skipping EE, no evidence.

~~~
tyingq
Looks like royalties are somewhere in the 2% range for ARM[1]. There's also
whatever markup companies like Marvell charge to WD. It sounds like WD sells
around 40 million drives per year. So, even a savings of 25 cents per unit
would be $10M/year.

[1] [https://www.anandtech.com/show/7112/the-arm-diaries-
part-1-h...](https://www.anandtech.com/show/7112/the-arm-diaries-part-1-how-
arms-business-model-works/2)

------
xvilka
Would have been awesome if they joined the effort of developing FIRRTL[1][2]
and using it as a universal (LLVM-alike) hardware intermediate language,
better suited modern chip design needs than Verilog or VHDL[3].

[1]
[https://github.com/freechipsproject/FIRRTL](https://github.com/freechipsproject/FIRRTL)

[2] [https://aspire.eecs.berkeley.edu/wp/wp-
content/uploads/2017/...](https://aspire.eecs.berkeley.edu/wp/wp-
content/uploads/2017/11/Reusability-is-FIRRTL-Ground-Izraelevitz.pdf)

[3]
[https://github.com/SymbiFlow/ideas/issues/19](https://github.com/SymbiFlow/ideas/issues/19)

~~~
NotCamelCase
It's a neat idea, but to me, that's like it. For SW, LLVM serves two-way:
1)target any (supported) arch you like with your language of choice,
2)customize your toolchain to generate native machine code (i.e. GPU shader
langauges) from any (supported) language.

I'd say putting yet another middleman between your logic compiler/netlist and
what you actually use is not the best course of action for HW implementations.
Even HLS has a big friction for use and is hardly picked up, with its obvious,
immediate advantages.

------
eternal_virgin
I've been meaning to get started with RISC-V for some time now but can't find
much on it for total beginners online. Can anyone recommend a starting point
for a total noob?

~~~
eBombzor
Since RISC-V uses Chisel instead of Verilog, you will probably need this
first: [https://github.com/freechipsproject/chisel-
bootcamp](https://github.com/freechipsproject/chisel-bootcamp)

For actually learning RISC-V, you can check out these books:
[https://riscv.org/risc-v-books/](https://riscv.org/risc-v-books/)

The Patterson and Hennessy book is a great starting point and the RISC-V
reader is great reference.

~~~
dooglius
> Since RISC-V uses Chisel instead of Verilog

What do you mean? The core here is entirely Verilog/SystemVerilog

~~~
eBombzor
Sorry I am an idiot how do I edit/delete my comment so I can erase this
misinformation?

~~~
yjftsjthsd-h
Unfortunately, if you don't see an edit button on the comment then you can't
edit it anymore. But props for admitting you're wrong and trying to correct it
:-)

------
gmueckl
So this is the logic of the controller in Verilog. But I don't see any test
scripts. I am not an expert in logic design, but it seems to me that
validation is at least as expensive and time consuming as the actual creation
because you cannot afford mistakes in the ASIC masks. Am I missing something
here?

~~~
sweden
You are correct. The most difficult part of a design is not the design itself,
it's all the documentation and the verification environment around it.

This is a nice gesture but hardware is a bit different than software and
dumping a bunch of RTL code is not really useful.

~~~
noobiemcfoob
A full environment that could get you to a blinking LED off of an FPGA would
be the complete dump, but I don't see the value in downplaying publishing a
bulk of code that all others have hidden behind lock and key.

------
Rochus
Great work, many thanks to WD. As far as I see only a subset of the
SystemVerilog features is used. Is there a "coding standard" somewhere
available specifying this subset with a rationale? Is it mostly to be
compatible with Verilator? Is there information available why they used
Verilator and how it has proven itself?

------
nraynaud
Can someone explain a bit what’s happening around the division?
[https://github.com/westerndigitalcorporation/swerv_eh1/blob/...](https://github.com/westerndigitalcorporation/swerv_eh1/blob/master/design/exu/exu_div_ctl.sv)

Or give me some google keywords? Is there a link with the pentium bug?

~~~
yjftsjthsd-h
This?
[https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug](https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug)

Edit: This is just the top result from
[https://duckduckgo.com/?q=pentium+cpu+bug](https://duckduckgo.com/?q=pentium+cpu+bug)

~~~
nraynaud
Link-> relationship

------
sitkack
Wester Digital if you are reading this!

Pleeeeze I want to have access as an end user. I'd like to do a predicate push
down and be able to write into the DRAM buffer and the flush a commit. Or pin
certain blocks directly into DRAM. Pleeeeze!

~~~
tyingq
This person got pretty far with the Marvell ARM WD drive controller in 2015:
[https://www.malwaretech.com/2015/04/hard-disk-firmware-
hacki...](https://www.malwaretech.com/2015/04/hard-disk-firmware-hacking-
part-1.html)

Also see:
[http://spritesmods.com/?art=hddhack&page=1](http://spritesmods.com/?art=hddhack&page=1)

------
equalunique
Shut up and take my money!

------
zapdrive
Is this code just for a processor, or an SOC? How is this different from the
open source Shakti processor being designed by IIT Chennai?

------
ngcc_hk
The link assume you know and this as well. May be in both has a few short
paragraph for those not in to appreciate and say thx you.

