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

[John Luke Gibson]

On 5/2/17, Pen-Yuan Hsing <penyuanhsing at gmail.com> wrote:
> 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/
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk

Print off some of the RISC-V technical documentation, write in the
link "http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-April/013457.html"
and leave the copies in cafes, coffee shops, computer labs, etc. Only
leave one copy per place. Some one will get curious I'm sure, and the
rest is up to them.