[libre-riscv-dev] formal verification

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Mar 20 07:26:18 GMT 2019


On Wed, Mar 20, 2019 at 7:14 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> All the legalese aside, we're going to try to be compliant with the RISC-V
> specs.

it's more than that, jacob: where it is not necessary for us to be
non-compliant (because there is no business case for doing so), we
must *not* be non-compliant.  to reiterate: where we have no *need* to
be non-compliant, we *cannot* be non-compliant.

or, we can be... but we must not at the same time claim
"compatibility".  the RISC-V Foundation has rather unfortunately
provided a "getout" clause that weakens the entire community, but
that's another story.

unfortunately, as far as creating a hybrid CPU / VPU / GPU is
concerned, we *can* clearly demonstrate a pressing business case for
stepping outside of the bounds of RISC-V Standards Compliance.  we can
also clearly demonstrate that RVV compliance is completely inadequate
for the purposes of creating a 3D GPU (lack of a Z-Buffer instruction,
for example).

our exclusion from interacting with other RISC-V Members means very
simply that, in order to meet the business goals, we are forced to
develop our own standard.  through this discrimination, waiting around
for the RISC-V Foundation to ratify a standard from which we are
*excluded* in participation provides the RISC-V Members who *are* free
to participate clearly gives them an unreasonable and unfair
competitive business advantage...

... oh and after waiting for that ratified standard it would be
extremely unlikely to meet our needs anyway.

so it's quite complex and quite unfortunate, and could be entirely
avoided if the RISC-V Foundation's Directors had any respect for the
libre business development process.

l.



More information about the libre-riscv-dev mailing list