In a privacy-respecting world neither of these are acceptable, therefore the goal is to develop - in an iterative fashion - not just the software but the actual hardware instructions (similar to ARM NEON) which, if fully integrated into libswscale, ffmpeg, gstreamer and other software, would make RISC-V a truly commercially competitive peer of ARM and x86 systems when it comes to video decode.
-There would thus be no opportunity and no excuse for the inclusion of spying hardware blocks or coprocessors.
+With such capability freely available, there would thus be no opportunity and no excuse for the inclusion of spying hardware blocks or coprocessors in modern RISC-V processors.
# 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?
* to implement those instructions in actual hardware, for running in an FPGA
* to follow through with the upstream submission and acceptance of customisation of relevant software libre video decode projects and toolchains.
-This needs to be done iteratively because it is only when a certain high level of functionality is reached (FPGA, full simulation) will it be possible to properly determine if the proposed instructions actually meet the requirements.
+This needs to be done iteratively because it is only when a certain high level of functionality is reached (FPGA, full simulation) will it be possible to properly determine if the proposed instructions actually meet the requirements. It may turn out that further optimisation is needed.
# Does the project have other funding sources, both past and present?
from NLNet. However that is for specifically covering the development
of the RTL (the hardware source code).
-There is no source of funds for the work on the
+There is no source of funds for the work on Video ISA development (only for its hardware implementation) or the follow through work which involves getting support for that ISA extension upstream in relevant software (ffmpeg, vlc, gstreamer) and toolchains (gcc, llvm, binutils)
# Compare your own project with existing or historical efforts.
-There are several Open VLSI Tool suites:
-
-* GNU Electric: https://www.gnu.org/software/electric/
-* MAGIC: http://opencircuitdesign.com/magic/
-* The OpenROAD Project: https://theopenroadproject.org/ (using MAGIC)
-* QFlow: http://opencircuitdesign.com/qflow/
-* Toped: http://www.toped.org.uk/
-
-and a few more. We choose Coriolis2 because of its python interface.
-The VLSI Layout is actually done as a *python* program. With nmigen
-(the HDL) being in python, we anticipate the same OO benefits to be
-achievable in coriolis2 as well.
-
-The case for the Libre RISC-V SoC itself was made already in the initial
-2018.02 proposal. That has not changed: there are no Libre / Open Projects
-approaching anything like the complexity and product market opportunities
-of the Libre RISC-V SoC, which is being designed to be a quad-core 800mhz
-multi-issue out-of-order design. All other Libre / Open processors such
-as Raven, and many more, have a goal set in advance not to exceed around
-the 350mhz mark, and are single-core.
-
-Other projects which are "open", such as the Ariane Processor, are
-developed by universities, and in the case of Ariane were *SPECIFICALLY*
-designed by and for the use of proprietary toolchains, such as those from
-Cadence, Synopsys and Mentor Graphics. Despite the source code being
-"open", there was absolutely no expectation that the processor of the
-same capability as the Libre RISC-V SoC would use Libre / Open tools.
-
-Although our first ASIC (thanks to Chips4Makers) will be only 180nm,
-single-core and a maximum of around 350mhz, this is just the first
-stepping stone to a much larger processor.
+There do exist on opencores a number of video encode and decode blocks: these are typically MPEG and h.264. In
## What are significant technical challenges you expect to solve during the project, if any?
projects / libreriscv.git / commitdiff