[libre-riscv-dev] [OpenPOWER-HDL-Cores] system call (sc) LEV "reserved field"
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Jul 27 10:43:34 BST 2020
On Mon, Jul 27, 2020 at 10:08 AM Hugh Blemings <hugh at blemings.org> wrote:
> Apologies for the top post but I can offer a historical perspective on
> at least part of this I think.
> 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
> 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.
> 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
*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.
More information about the libre-riscv-dev