On Fri, Apr 28, 2017 at 11:29 AM, mike.valk@gmail.com mike.valk@gmail.com wrote:
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.
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.