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

[David Niklas]

I apologize for DOS'ing the list, I can only get online about once a week.

On Fri, 28 Apr 2017 12:35:19 +0200
"mike.valk at gmail.com" <mike.valk at gmail.com> wrote:
> 
> 2017-04-27 13:21 GMT+02:00 Luke Kenneth Casson Leighton
>> <lkcl at lkcl.net>:
> 
> > 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
Links?


> > for this first phase the interfaces that i've tracked down so far are
> > almost entirely from 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)
> >  
> 
> Perhaps put it sirectly to an USB bridge. UART's on debugging hardware
> is non existant. We all use FTDI dongles.
> 
> Look like OpenCores has a module. https://opencores.org/project,usb2uart
> 
> 
> 
> > * 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.

Considering that analog was around *long* before digital I'm surprised
that it is "Hard to get right", is there a reason for this?
Isn't there a chip for just this kind of thing?

> > 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
Hmm, I can't seem to google that piece of SW. Do you have a link?

> > 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.

How would you get it in the first place?
Is there a company dedicated to larger than industry standard (nm)
silicon production for small businesses, or are you planning to buy a ...
what would it be called? ... printed wafer producer?

> > 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.
<snip>

What about Vulkan?
I'm asking, because it is multithreaded, as opposed to OpenGL. I've also
heard, though perhaps the person was wrong, that it is supposed to
replace OpenCL.