On Fri, Apr 28, 2017 at 11:29 AM, mike.v...@gmail.com <mike.v...@gmail.com> wrote: > > > 2017-04-27 13:21 GMT+02:00 Luke Kenneth Casson Leighton <l...@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. _______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
