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

[Luke Kenneth Casson Leighton]

On Fri, Apr 28, 2017 at 11:29 AM, 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.
>
>
> That's one hornet nest you're going into.

 yyyup.  am tracking down the pieces.

> But I'd really like to see you pull it off.

 like a quantum electron it'll probably happen because i forget to
look backwards :)

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

 not for the first proof-of-concept SoC... unless the external PHY
which will be wired to the ULPI (PHY) interface happens to support
USB-C.

 the *mass-volume* SoC: yes, great idea.

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

 remember that 90nm is a maximum clock rate if you're really really
lucky of 400mhz: 300mhz is more realistic.  65nm you get maybe 700mhz
absolute max.

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

 that would be a big advantage.

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

 yeah.

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

 at the expense of power consumption.


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

 it's not quite that simple, but yes :)

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

 yep it's out for this SoC.

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

 yeahyeah.  well, the embedded market is where the RV32* is already
being targetted (sifive, pulpino) - there's nobody however who's
started on RV64 because it's a whole different beast.  64-bit is
usually deployed where performance is a priority (i.e. by definition
space-saving being diametrically the opposite isn't) and that means
DDR3 external RAM instead of e.g. 48k of *internal* SRAM... and many
other things.

> Besides the max for silicon scaling is nearing. EULV is still not generally
> available.
>
> Better architectures are needed. Just like better programming.

 40% better performance-watt is a good enough indicator to me.

l.