
Seventh RISC-V Workshop: Day One - bshanks
http://www.lowrisc.org/blog/2017/11/seventh-risc-v-workshop-day-one/
======
rwmj
For those not following RISC-V closely, 2018 promises to be an interesting
year:

* 64 bit hardware will be available from SiFive. It'll be low-ish end, 4 application cores, but it'll run real Linux distros. SiFive are already shipping early hardware to various partners.

* Linux 4.15 will ship with RISC-V support. It's available in RC releases now. (-rc1 was 3 days ago I think)

* glibc will ship RISC-V support. That'll happen in February 2018. I think it's not appreciated how important this is. It means there will be a stable ABI to develop against, and we won't need to re-bootstrap Linux distros again.

* GCC and binutils have been upstream for a while.

* A lot of other projects have been holding off integrating RISC-V-related support and patches until RISC-V "gets real", ie. it's really available in the kernel, there's hardware. These projects are unblocked.

* Fedora and Debian bootstrapping will kick off (again). [Disclaimer: I'm the Fedora/RISC-V maintainer, but I'm also getting everything upstream and coordinating with Debian]

* There'll be finalized specs for virtualization, no hardware though.

* There should be at least a solid draft of a spec for industrial/server hardware. Of course no server-class hardware available for a while.

~~~
gorbypark
Has SiFive released any dates for their dev board that can run Linux? I
haven't been following it to closely but would love to get one.

~~~
baobrien
My reading of the blog post is that it'll be released in Q1 of 2018. Until
then, they're giving a few FPGA stand in boards out. The dev board itself will
also use an FPGA to implement a few SoC peripherals, like USB and HDMI.

~~~
rwmj
Actually they are sampling the real chips out to some developers now. However
you are correct in saying that an FPGA is used to implement the Southbridge,
which is mainly for practicality of getting a board out quickly, not because
of awesome self-modifying hardware(!)

------
jabl
And day two: [http://www.lowrisc.org/blog/2017/11/seventh-risc-v-
workshop-...](http://www.lowrisc.org/blog/2017/11/seventh-risc-v-workshop-day-
two/)

~~~
AllSeeingEye
"Boomv2 achieves 3.92 CoreMark/MHz (on the taped out BOOM), vs 3.71 for the
Cortex-A9." \- it's a bit of a letdown. I was hoping it'd be closer to x64
performance than to Cortex-A, but it's probably not achievable for RICS-V
budget.

~~~
_chris_
Sorry to disappoint, AllSeeingEyes. What I taped out is a fairly modest
instantiation of BOOM. I was trying to reduce risk and we had a very small
area to play with, so I settled for ~4 CM/MHz. One potential win here would
have been to use my TAGE-based predictor, which is an easy >20% IPC
improvement on Coremark. Of course, a lot more reworking would be needed to
achieve x86-64 clock frequencies.

~~~
microcolonel
> which is an easy >20% IPC improvement on Coremark. Of course, a lot more
> reworking would be needed to achieve x86-64 clock frequencies.

Maybe these should be expressed as Instructions Per Second (at peak and at the
point of diminishing returns?) or something like that, rather than two
independent numbers. Higher clock frequency actually seems like a _bad_ thing,
all else being equal. It seems to me that throughput ought to trend toward
infinity, clock frequency toward zero. ;- )

~~~
_chris_
Of course it's important to always keep the "Iron Law" in mind, but it's far
easier to compare ideas and talk about things in terms of IPC. For example, if
a switch out one branch predictor for another, we're talking about an
algorithmic change (implemented in hw) that will have an effect on IPC, and no
effect on clock period (assuming we didn't screw something up).

This is particularly useful when talking about a processor _design_ , and not
a specific processor in particular. As you said, there's a lot of good about
slower clock frequencies, so you'll see the same ARM design being deployed at
a variety of frequencies. Far easier to talk separately about a design's IPC
from its achievable clock frequency (although both are important!).

------
x0ul
I've been following developments in RISC-V since I first heard about it a few
months ago and I want to get involved! What can I do? I do embedded systems
development as my day job and am really eager to dig into architecture and
hardware design.

Can somebody associated with the project reach out to me?

~~~
nickik
The lowrisc project [1] tires to be sort like a hardware linux. They are
working on a linux capable SOC and they have a number of innovative ideas you
might be interested in.

Maybe listen to this maybe:
[https://www.youtube.com/watch?v=it3vVtnCYiI](https://www.youtube.com/watch?v=it3vVtnCYiI)

[1] [http://www.lowrisc.org/](http://www.lowrisc.org/)

------
greenhouse_gas
Practically, what's stopping someone from making a privacy-oriented ARM
implementation (meaning, while I can't "make my own" ARM board due to patents,
why can't I make a board which is "source-available" and doesn't contain a ME
or PSP-like engine)?

Is there something in the ARM license?

~~~
subway
A ton of ARM boards like this already exist. You can bring up most Allwinner
chips with 100% open source code. The bootmask from for many have been dumped
and disassembled even.

The trouble is they all suck in some slightly different way. Maybe only 1gb
ram, maybe a bottleneck bus in front of your net or storage io. Graphics are
the big pain point right now. Etnaviv/vivante is your only choice for free
accelerated graphics, and you'll only find it in a few chips. Mali and PowerVR
are all around, but have absurdly difficult to work with closed source
drivers.

The nicest oss-all-the-way-down arm socs are i.MX6, which is expensive and
frankly old/slow.

To be clear: riscv doesn't solve any of these concerns. That doesn't mean it
isn't an amazing project.

~~~
greenhouse_gas
So how will RISC-V help? Do ARM patents cost that much to license?

~~~
subway
RISC-V doesn't directly help with _any_ of these concerns.

But it is an alternative to ARM, and has a governance model that parties
interested in open standards might be more willing to join.

Right now, ARM CPUs on the low end have little standardization at the SOC
level. They have a few cores from ARM, (what you think of as the main CPU,
maybe a GPU, maybe a low end micro for power management, and a couple more for
realtime tasks). Then you have the non-ARM IP in the form of image processors
for cameras, video decoding, etc. The SoC mfg is responsible for gluing
together all these parts, and every mfg has their own proprietary take on the
process, meaning a different initialization sequence, different firmware
layouts, etc.

The SoC mfg's goal is to ship a product. It isn't to define a standard, and
since there is no standard to follow, 'anything' goes.

Because ARM costs enough that it isn't viable to do a SoC layout you aren't
going to ship millions of the chip, academic research (where the seeds for
standards are often planted) just doesn't happen.

~~~
greenhouse_gas
>Because ARM costs enough that it isn't viable to do a SoC layout you aren't
going to ship millions of the chip, academic research (where the seeds for
standards are often planted) just doesn't happen.

Is it license or fab issues? I thought that license is $0.X per chip, so it
shouldn't make a difference (license-wise) if you make Y chips or 100,000 * Y
chips. Fab costs change by overhead, but how would RISC-V help there?

~~~
subway
It's a mix of upfront costs and per-chip royalties, with upfront costs for the
IP being in the millions.

Here's a somewhat accurate article on the topic:
[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)

------
makomk
I know at least Allwinner were using OpenRISC for their embedded controller on
recent chips, and it wouldn't surprise me if other companies were doing the
same, so I do wonder to what extent RISC-V is replacing that rather than
commercial cores for this application.

------
sitkack
These notes are wonderfully detailed and compact. Please do this for all my
meetings!

~~~
asb
I'm glad you find them useful. Really I'm indebted to the presenters for
giving such clear and well explained presentations.

------
mycall
I wonder what Microsoft will do with RISC-V. Hopefully they don't think it is
too risk-y.

