# NL.net proposal - 2019-10-046

* NLNet Project Page <https://nlnet.nl/project/LibreSoC-Standards/>
* Top Level bugreport <http://bugs.libre-riscv.org/show_bug.cgi?id=174>

## Project name

The Libre RISC-V SoC, Formal Standards Development

## Website / wiki 

<https://libre-riscv.org/nlnet_2019_standards>

Please be short and to the point in your answers; focus primarily on
the what and how, not so much on the why. Add longer descriptions as
attachments (see below). If English isn't your first language, don't
worry - our reviewers don't care about spelling errors, only about
great ideas. We apologise for the inconvenience of having to submit in
English. On the up side, you can be as technical as you need to be (but
you don't have to). Do stay concrete. Use plain text in your reply only,
if you need any HTML to make your point please include this as attachment.

## Abstract: Can you explain the whole project and its expected outcome(s).

The Libre RISC-V SoC is a hybrid CPU, VPU and GPU which is being designed
to be libre to the bedrock. When the hardware is transparently auditable,
it can be trusted to not secretly compromise the software running on it.

With RISC-V being in its early infancy, however, Standards for Video
Acceleration and 3D Graphics Acceleration do not yet exist.  These need
to be written, proposed, formally ratified and Conformance Test Suites
written and likewise ratified.

This takes a huge amount of time and coordinated collaboration, and is
a necessary co-dependent task alongside the actual development of the
processor itself.


# Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?

Luke Leighton is an ethical technology specialist who has a consistent
24-year track record of developing code in a real-time transparent
(fully libre) fashion, and in managing Software Libre teams. He is the
lead developer on the Libre RISC-V SoC.

# Requested Amount

EUR 50,000.

# Explain what the requested budget will be used for?

The improvements and additions to RISC-V Standards (known as Extensions)
need to be written, reviewed thoroughly, justification for the features
given, and then proposed.

There are several (see links at end) already in draft form. The primary
one is the Vectorisation Standard. Additional Vector Operations is
another. Transcendental operations (SIN, COS, LOG) another.

Once drafts have been agreed, a simulator can be developed. Next is some
unit tests, and after that, some formal Compliance Tests.

Finally this can be submitted to the RISC-V Foundation for formal
adoption.

Traveling expenses for presenting the standards to the RISC-V community
at Libre Conferences as well as RISC-V Workshops are needed.

Writing up of papers on the core technology and discoveries behind the
standards, for presentation at IEEE and other Computing Conferences.
This to aid in understanding of the need for the Standards and to
make adoption easier.

# Does the project have other funding sources, both past and present?

The initial proposal in November 2018 was for implementation of the
actual processor, as well as writing a simulator and developing Kazan,
the 3D Vulkan Driver. Purism began also sponsoring the overall project
in mid 2019.

It was discovered only in September 2019 on an offchance comment from
someone inside the (closed participation) RISC-V Foundation that RISC-V
Standards require a full Conformance Compliance Test Suite as part
of formal acceptance.  This easily doubles the workload of Standards
Development and is in no way coverable by the initial 2018 proposal.

# Compare your own project with existing or historical efforts.

RISC-V is in its early infancy and has neither Extensions for 3D nor
Video.  Most off the shelf commercial SoCs will use a special custom block
for Video, and a separate GPU for 3D. Each of these, bring proprietary,
is an attack vector for privacy subversion.

In this project, the CPU *is* the VPU and the GPU, so there is nothing to
compare it against.  The full transparency of the Standards Development
Process is a necessary prerequisite for being able to trust the end
result.

## What are significant technical challenges you expect to solve during the project, if any?

The key challenge will not be technical, it is a communications issue. The
RISC-V Foundation operates as a closed ITU Style Standards Organisation,
requiring effectively an NDA for participation, with negligeable
transparency and zero accountability.

A two year protracted and persistent request for open participation
and recognition of the value of the same is finally starting to get
action taken.

## Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes

As mentioned in the 2018 submission, the Libre RISC-V
SoC has a full set of resources for Libre Project Management and development:
mailing list, bugtracker, git repository and wiki - all listed here:
<https://libre-riscv.org/>

In addition, we have a Crowdsupply page
<https://www.crowdsupply.com/libre-risc-v/m-class> which provides a public
gateway, and heise.de, reddit, phoronix, slashdot and other locations have
all picked up the story.  The list is updated and maintained here:
<https://libre-riscv.org/3d_gpu/>

# Extra info to be submitted

* <http://libre-riscv.org/3d_gpu/>
* <https://nlnet.nl/project/Libre-RISCV/>
* <https://libre-riscv.org/simple_v_extension/>
* <https://libre-riscv.org/ztrans_proposal/>
* <https://libre-riscv.org/zfpacc_proposal/>
* Several other sub-proposals as part of the above.

# Management Summary

The Libre SoC was first funded from NLNet in 2018.  This was for the core
of the project, based on an informally-developed Hybrid CPU-GPU 3D
instruction set that had been written (and implemented in a simulator)
in the 18 months prior to contacting NLNet.  During the implementation
it became clear that a lot more work would be needed, and, further, that
to meet proper transparency criteria, the proposed instruction set
enhancements would need to be properly written up.  In addition,
negotiations and communications with the Standards Body responsible
for POWER ISA (the OpenPower Foundation) also needed to be taken into
consideration.  Therefore this proposal was submitted so that full
transparency and understanding of the Libre SoC is achieved.