## Project name
-The Libre RISC-V SoC, Wishbone Streaming Proposal
+The Libre RISC-V SoC, Formal Standards Development
## Website / wiki
-<https://libre-riscv.org/nlnet_2019_wishbone_streaming>
+<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
## Abstract: Can you explain the whole project and its expected outcome(s).
-In projects such as the Libre RISC-V SoC, commercial grade System-on-Chip
-(SoC) bus infrastructure is needed. Nowadays this often means AMBA AXI4,
-AXI4-lite or AXI4-Stream, all published by ARM Limited. The AXI family is
-"royality-free" and it is not only patented but its patent holder has
-begun denying licenses due to the US Trade War.
+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.
-The main alternative with large adoption is Wishbone, which is an Open
-Standard in contrast to AXI. However Wishbone does not have a "streaming"
-capability, which is typically needed for high-throughput data pathes and
-interfaces, e.g. for video applications and High-Performance Computing
-(HPC).
+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.
-Therefore this project will write up an enhancement to the Wishbone B4 SoC
-Bus, provide Reference Implementations and Bus Function Models (BFM) which
-easily allows unit tests for all Wishbone BFM users. For demonstration
-we like to implement an example peripheral (here, an audio interface, for
-the Libre RISC-V SoC) also. This demonstrations proves our concept also.
+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.
-A secondary objective will be to seek out Reference Implementations for
-Wishbone Master and Slave, provide formal correctness proofs, and add
-additional example peripherals - non-streaming ones - as resources permit.
# 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?
(fully libre) fashion, and in managing Software Libre teams. He is the
lead developer on the Libre RISC-V SoC.
-Hagen Sankowski is a Senior ASIC Design Engineer, with 20-year Experiences
-thru the whole Design Flow, from Digital Entry (Verilog HDL, VHDL) to
-DSM Backend and back. He has FPGA knowledge for Xilinx, Altera, Lattice
-and MicroSemi. Inventor and Patentee for a FPGA structure. Open Source
-Evangelist, member of the LibreSilicon project Team also.
-
# Requested Amount
EUR 50,000.
# Explain what the requested budget will be used for?
-Improve the Wishbone B4 Specification to add streaming capability,
-comparable to AXI4-Stream, and feed the improvements back into the
-current stewardship for next Wishbone release.
+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. Ttranscendental operations (SIN, COS, LOG) another.
-Design Reference Implementations in nmigen and (System-)Verilog, Bus
-Function Models and other functionality in SystemVerilog for verification
-with full unit tests aiming best code coverage.
+Once drafts have been agreed, a simulator can be developed. Next is some unit tests, and after that, some formal Compliance Tests.
-Use some of the Libre RISC-V SoC peripherals as a test platform
-and demonstrator (I2S Audio Streaming) for the proposed standard
-modifications.
+Finally this can be submitted to the RISC-V Foundation for formal adoption.
-Traveling expenses for presenting the Wishbone improvements to the RISC-V
-community once at the annual ORConf in 2020.
+Traveling expenses for presenting the standards to the RISC-V
+community at Libre Conferences as well as RISC-V Workshops.
-As a secondary objective: seek out existing (non-streaming) Wishbone
-Master and Slave Bus implementations (or implement them if necessary),
-provide formal proof unit tests of their correctness, and add additional
-example peripherals.
+Writing up of papers on the core technology and discoveries behind the standards, for presentation at IEEE and other Computing Conferences.
# Does the project have other funding sources, both past and present?
-The concept of extending Wishbone to have streaming capability is entirely
-new: it has no source of funding.
+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.
-The Libre RISC-V SoC has funding from NLNet under a 2018 Grant: it was
-intending to use AXI4 prior to the U.S. Trade War.
+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.
-AXI4 has streaming (as AXI4-Stream) but it is proprietary and patented.
+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.
-TileLink is an alternative protocol (with roots in the RISC-V academic
-community) but it is relatively new, quite complex, and does not have
-the same adoption as Wishbone.
+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.
-There do exist a number of pre-existing Wishbone Bus Master and
-Slave implementations: Wishbone has been around for a significantly
-long time and has been the de-facto choice in the Libre/Open Hardware
-community. Formal correctness proofs for Wishbone have been written by
-Dan Gisselquist in SystemVerilog, but none are written in nmigen.
## What are significant technical challenges you expect to solve during the project, if any?
-This is a straightforward project. However the timing issues involved
-with Bus Negotiation can be awkward to get right and may need formal
-proofs to properly verify. Dan Gisselquist's work in his area shows
-how it can be done.
+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
* <http://libre-riscv.org/3d_gpu/>
* <https://nlnet.nl/project/Libre-RISCV/>
+* <>
projects / libreriscv.git / commitdiff