[libre-riscv-dev] LibreSOC - RISCV and POWER dual architecture feasibility

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sun Mar 15 04:00:30 GMT 2020

On Sun, Mar 15, 2020 at 3:17 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Sat, Mar 14, 2020, 18:01 Immanuel, Yehowshua U <yimmanuel3 at gatech.edu>
> wrote:
> > Hello Jacob,
> >         I’m running through the numbers and studying LibreSOC’s potential
> > markets, and how we’d market the dual architecture.
> > Just how feasible is the dual architecture we’re currently embarking on.
> > Luke says its doable.
> > What are your thoughts, and what are the challenges - just trying to get a
> > comprehensive understanding.
> >
> It will be quite easy to do from the hardware side due to the relative
> simplicity of user-mode RV64GC -- basically all we need is to do is
> implement the instruction decoder and clean up the odds and ends that
> result from the semantic differences.

pretty much.  the RV64GC decoder would map onto the exact same
internal operations (the ones that anton blanchard started), and we
would expand those as necessary.

however that's not the main problem

we actually have a serious "bootstrap" problem in terms of implementing POWER.

here's how it works with RISC-V:

* take spike, and add SimpleV (done - took 2-3 months appx)
* take riscv-isa-tests, and add SimpleV unit tests (done - took about 1 month)
* implement a core in hardware by taking an existing core and adding
in our engine.

hardware is bootstrapped.  it's done in an incremental fashion, *one*
unknown at a time.

now let's look at POWER.

1) where are the unit tests?
2) where is the simulator?
3) where is the port of softfloat-3 that supports POWER IEEE754 format?

and on top of this *NON-EXISTENT* (or barely adequate) code, we want
to add a vectorisation system, *and then implement it in hardware*?

that's a minimum of *five* extremely large unknowns.

we therefore have two potential approaches (which we may have to do in

1) getting a power isa cycle-accurate simulator plus unit tests is
absolutely essential.

2) getting the core working by bootstrapping up in only *one* unknown
at a time, and that means RISC-V.

as (1) is a software-only effort, we can continue with (2) to keep
hardware-people busy and occupied.


More information about the libre-riscv-dev mailing list