2017-04-27 13:21 GMT+02:00 Luke Kenneth Casson Leighton <lkcl@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.

That's one hornet nest you're going into. But I'd really like to see you pull it off.

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 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)
* OpenCores VGA controller (actually it's an LCD RGB/TTL controller)
* OpenCores ULPI USB 2.0 controller
* OpenCores USB-OTG 1.1 PHY

I'm not much into HW design. But I think it would be wise to aim for USB-C connectivity.

USB-C does not imply USB3.0 AFAIKT.

USB-C has to option of channeling USB2/3,HDMI,DP via the alternate modes and power. So a stack of USB-C connectors on the User Facing Side would be awesome.

It would also limit the need for other connectors and PHY's.

The problem is MUXing all modes to a single output. New Apple laptops have USB-C but not all ports support all functions.

Perhaps a bit of FPGA could be the key?

Ethernet over UCB-C is still being discussed. So the FPGA might be handy to have when/if that mode is materialized.

A bit of FPGA would be nice to have anyway. Media codecs keep on changing and would extend the life of the SoC.

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.

That's what phy's are for right?

VGA is on decline I would bother with it too much. But that's personal.

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.

I Don't think speed is to much of an issue right now. Having something workable like this, even only suitable for embedded use, would gain traction fast enough to get attention and help for new revisions with smaller and faster production.

Besides the max for silicon scaling is nearing. EULV is still not generally available.

Better architectures are needed. Just like better programming.

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 notes http://rhombus-tech.net/riscv/libre_riscv/

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

_______________________________________________
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@files.phcomp.co.uk