[libre-riscv-dev] Introduction and Questions

[Yehowshua]

> 
> I'm a bit confused now. In-order execution with variable-latency
> functional units can be achieved with a scoreboard, and the pipeline
> stages you describe reminds me of a in-order core with OOO write-back.
> Is this what you are doing? Or are you pursuing true OOO execution
> with register-renaming?
> 

Register renaming I believe.

> Have you looked at the open RISC-V micro-architectures though? Even if
> this core runs POWER, it should be not too difficult to port design
> ideas from existing cores, to avoid reinventing the wheel everywhere.
> 

Yeah - there was a thought to use a RISC-V like microarchitecture.
And then do POWER ontop of that.

There are a couple things to consider.

1. SPR registers and TLB and cache behavior are notably different for POWER.
2. All the RISC-V instructions exist in POWER in some form. POWER’s extra instructions
can be composed of simpler instructions - but it may not be worth it

Consider the instruction the POWER instruction ``rlwinm``:
That does a bit rotate - can we guarantee that implementing hardware to translate ``rlwinm`` into some sequence of ``sll``and ``and`` will actually be easier?

We didn’t really have the time or labor to investigate in February.

Before that, we did however do an extensive investigation of RISC-V.
We concluded that the POWER software ecosystem is more mature, for example, POWER has
a well maintained port of V8 as well as a complete vector extension.

Since we wanted to use a vector like extension to implement our GPU, we didn’t want to release an SOC with its own RISCV vector extension, and then perhaps when RISCV in the future finalized their extension, ours would be out of date.

After talks with the OpenPOWER organization, we are allowed to implement special instructions as necessary while still maintaining the official POWER compliance of our chip.

The instructions we implement will be subject to review, but we’ve had healthy dialogue with the POWER foundation.

After some discussion with RVF, we weren’t sure if our chip would be deemed officially RISCV compliant with custom and potentially future conflicting custom instructions.

Yehowshua