[libre-riscv-dev] [OpenPOWER-HDL-Cores] system call (sc) LEV "reserved field"

[Luke Kenneth Casson Leighton]

On Mon, Jul 27, 2020 at 10:08 AM Hugh Blemings <hugh at blemings.org> wrote:
>
> Hiya,
>
> Apologies for the top post but I can offer a historical perspective on
> at least part of this I think.

appreciated.

> Before I do though a disclaimer - these are my opinions and
> recollections only, certainly not policy! :)

always important to know where things are coming from.

> While it may change over time, the focus for OpenPOWER in the embedded
> space with the Open ISA has been firmly in the mid to high end and
> therefore mostly 64 bit space.

you may be interested to know that Andes Technology (a company in
Taiwan that has traditionally done DSPs focussing on audio processing:
think e.g. "C-Media" USB Audio devices: massive volume) has become the
de-facto creator and maintainer of RV32 Linux.

this because whilst everyone else is abandoning 32-bit because
640k^H^H^H^H 4GB should be enough for everyone, turns out this isn't
true any more thanks mostly to web browser memory consumption, Andes
Technology recognises that, in the huge market their customers *need*
the space and power saving that comes with a 32 bit ISA.

and it's enormous.

the jump in power consumption suffered by ARM when they went from the
32-bit Cortex A7 (which has a 48-bit address space) to the 64-bit
Cortex A53 was a whopping 10 to *15* percent for the same level of
DMIPS and actual real-world performance.

this because the increase in instruction length that inherently goes
with a 64 bit ISA required vendors using the Cortex A53 to lay down an
extra 50% larger L1 I-Cache.  with L1 caches being a major part of
power consumption, real-world performance/watt figures took a
nose-dive.


> So to borrow some of the terminology/examples below, a SoC for a
> Raspberry Pi style device based on OpenPOWER ?  Sure, definitely an area
> of interest.

cool.

> Getting down into smaller devices - really resource constrained and/or
> native 32 bit only - "truly embedded" - that's an area well served by
> RISC-V and not, I think somewhere we're going to see focus for OpenPOWER
> at present.

the advantage that they had was not being constrained by what is,
slightly unfairly / inaccurately, termed "mistakes of the past".  they
had a clean sheet, basically.

could OpenPOWER follow that?  with careful planning, and given the
care that's already been taken (as Paul mentioned), quite probably
yes.

*should* the OpenPOWER Foundation Members get together and work on
that?  mmm... there would have to be clear benefits and a chance of
market success and adoption that warranted the effort.  and, i think,
here, given that as you say, RISC-V already serves this area well,
it's not clear that it would be worthwhile doing.

i.e. unless it's something that was invested in (multi-year) by
something Foundation-like and University-collaboration-like (with
associated large DARPA/other Grants to back it up, as happened with
RISC-V) you'd need a well-funded OPF stakeholder that was actively
interested in pursuing it, and given the resources involved they'd
more than likely evaluate RISC-V as the better cost-benefit option.


> Not to say it can't in the future, but I think there is a bias towards
> working in areas the ecosystem as it currently stands knows well -
> playing to current strengths. :)

yeh absolutely.  incremental steps, with consensus.

> That said I may still do an OpenPOWER based NTP enabled 7-segment
> display bedside clock one day, but that will be born of stubbornness,
> not because I actually need a 64 bit CPU to do it ;)

:)  with added realistic and annoying analog buzzer alarm (a la
Groundhog Day), to boot.

l.