[Arm-netbook] libre 64-bit risc-v SoC

[Pen-Yuan Hsing]

I'm really really excited about a possible 100% libre RISC-V based computer.
Though I'm a backer of the most recent campaign (and can't wait to get it! :)), I lack the knowledge/skills to actually help with the technical development of this upcoming RISC card.
Is there anything I/we can do to help get this RISC initiative going?

On 2017-04-28 08:36, Allan Mwenda wrote:
> Yes. Do it. DO IT.
> 
> On 27 April 2017 14:21:08 GMT+03:00, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
>     ok so it would seem that the huge amount of work going into RISC-V
>     means that it's on track to becoming a steamroller that will squash
>     proprietary SoCs, so i'm quite happy to make sure that it's
>     not-so-subtly nudged in the right direction.
> 
>     i've started a page where i am keeping notes:
>     http://rhombus-tech.net/riscv/libre_riscv/ and the general goal is to
>     create a desirable mass-volume low-cost SoC, meaning that it will need
>     to at least do 1080p60 video decode and have 3D graphics capability.
>     oh... and be entirely libre.
> 
>     the plan is:
> 
>     * to create an absolute basic SoC, starting from lowRISC (64-bit),
>     ORGFX (3D graphics) and MIAOW (OpenCL engine), in at least 90nm as a
>     low-cost proof-of-concept where mistakes can be iterated through
>     * provide the end-result to software developers so that they can have
>     actual real silicon to work with
>     * begin a first crowd-funding phase to create a 28nm (or better)
>     multi-core SMP SoC
> 
>     for this first phase the interfaces that i've tracked down so far are
>     almost entirely fromopencores.org <http://opencores.org>, meaning that there really should
>     be absolutely no need to license any costly hard macros.  that
>     *includes* a DDR3 controller (but does not include a DDR3 PHY, which
>     will need to be designed):
> 
>     * DDR3 controller (not including PHY)
>     * lowRISC contains "minion cores" so can be soft-programmed to do any GPIO
>     * boot and debug through ZipCPU's UART (use an existing EC's on-board FLASH)
>     * OpenCores VGA controller (actually it's an LCD RGB/TTL controller)
>     * OpenCores ULPI USB 2.0 controller
>     * OpenCores USB-OTG 1.1 PHY
> 
>     note that there are NO ANALOG INTERFACES in that.  this is *really*
>     important to avoid, because mixed analog and digital is incredibly
>     hard to get right.  also note that things like HDMI, SATA, and even
>     ethernet are quite deliberately NOT on the list.  Ethernet RMII (which
>     is digital) could be implemented in software using a minion core.  the
>     advantage of using the opencores VGA (actually LCD) controller is: i
>     already have the full source for a *complete* linux driver.
> 
>     I2C, SPI, SD/MMC, UART, EINT and GPIO - all of these can be
>     software-programmed as bit-banging in the minion cores.
> 
>     these interfaces, amazingly, are enough to do an SoC that, if put into
>     40nm, would easily compete with some of TI's offerings, as well as the
>     Allwinner R8 (aka A13).
> 
>     i've also managed to get alliance and coriolis2 compiled on
>     debian/testing (took a while) so it *might* not be necessary even to
>     pay for the ASIC design tooling (the cost of which is insane).
>     coriolis2 includes a reasonable auto-router.  i still have yet to go
>     through the tutorials to see how it works.  for design rules: 90nm
>     design rules (stacks etc.) are actually publicly available, which
>     would potentially mean that a clock rate of at least 300mhz would be
>     achievable: interestingly 800mhz DDR3 RAM from 2012 used 90nm
>     geometry.  65 down to 40nm would be much more preferable but may be
>     hard to get.
> 
>     graphics: i'm going through the list of people who have done GPUs (or
>     parts of one).  MIAOW, Nyuzi, ORGFX.  the gplgpu isn't gpl. it's been
>     modified to "the text of the GPL license plus an additional clause
>     which is that if you want to use this for commercial purposes then...
>     you can't". which is *NOT* a GPL license, it's a proprietary
>     commercial license!
> 
>     MIAOW is just an OpenCL engine but a stonking good one that's
>     compatible with AMD's software.  nyuzi is an experimental GPU where i
>     hope its developer believes in its potential.  ORGFX i am currently
>     evaluating but it looks pretty damn good, and i think it is slightly
>     underestimated.  i could really use some help evaluating it properly.
>     my feeling is that a combination of MIAOW to handle shading and ORGFX
>     for the rendering would be a really powerful combination.
> 
>     so.
> 
>     it's basically doable.  comments and ideas welcome, please do edit the
>     page to keep track of noteshttp://rhombus-tech.net/riscv/libre_riscv/