<html><head></head><body>Yes. Do it. DO IT. <br><br><div class="gmail_quote">On 27 April 2017 14:21:08 GMT+03:00, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">ok so it would seem that the huge amount of work going into RISC-V<br />means that it's on track to becoming a steamroller that will squash<br />proprietary SoCs, so i'm quite happy to make sure that it's<br />not-so-subtly nudged in the right direction.<br /><br />i've started a page where i am keeping notes:<br /><a href="http://rhombus-tech.net/riscv/libre_riscv">http://rhombus-tech.net/riscv/libre_riscv</a>/ and the general goal is to<br />create a desirable mass-volume low-cost SoC, meaning that it will need<br />to at least do 1080p60 video decode and have 3D graphics capability.<br />oh... and be entirely libre.<br /><br />the plan is:<br /><br />* to create an absolute basic SoC, starting from lowRISC (64-bit),<br />ORGFX (3D graphics) and MIAOW (OpenCL engine), in at least 90nm as a<br />low-cost proof-of-concept where mistakes can be iterated through<br />* provide the end-result to software developers so that they can have<br />actual real silicon to work with<br />* begin a first crowd-funding phase to create a 28nm (or better)<br />multi-core SMP SoC<br /><br />for this first phase the interfaces that i've tracked down so far are<br />almost entirely from <a href="http://opencores.org">opencores.org</a>, meaning that there really should<br />be absolutely no need to license any costly hard macros.  that<br />*includes* a DDR3 controller (but does not include a DDR3 PHY, which<br />will need to be designed):<br /><br />* DDR3 controller (not including PHY)<br />* lowRISC contains "minion cores" so can be soft-programmed to do any GPIO<br />* boot and debug through ZipCPU's UART (use an existing EC's on-board FLASH)<br />* OpenCores VGA controller (actually it's an LCD RGB/TTL controller)<br />* OpenCores ULPI USB 2.0 controller<br />* OpenCores USB-OTG 1.1 PHY<br /><br />note that there are NO ANALOG INTERFACES in that.  this is *really*<br />important to avoid, because mixed analog and digital is incredibly<br />hard to get right.  also note that things like HDMI, SATA, and even<br />ethernet are quite deliberately NOT on the list.  Ethernet RMII (which<br />is digital) could be implemented in software using a minion core.  the<br />advantage of using the opencores VGA (actually LCD) controller is: i<br />already have the full source for a *complete* linux driver.<br /><br />I2C, SPI, SD/MMC, UART, EINT and GPIO - all of these can be<br />software-programmed as bit-banging in the minion cores.<br /><br />these interfaces, amazingly, are enough to do an SoC that, if put into<br />40nm, would easily compete with some of TI's offerings, as well as the<br />Allwinner R8 (aka A13).<br /><br />i've also managed to get alliance and coriolis2 compiled on<br />debian/testing (took a while) so it *might* not be necessary even to<br />pay for the ASIC design tooling (the cost of which is insane).<br />coriolis2 includes a reasonable auto-router.  i still have yet to go<br />through the tutorials to see how it works.  for design rules: 90nm<br />design rules (stacks etc.) are actually publicly available, which<br />would potentially mean that a clock rate of at least 300mhz would be<br />achievable: interestingly 800mhz DDR3 RAM from 2012 used 90nm<br />geometry.  65 down to 40nm would be much more preferable but may be<br />hard to get.<br /><br />graphics: i'm going through the list of people who have done GPUs (or<br />parts of one).  MIAOW, Nyuzi, ORGFX.  the gplgpu isn't gpl. it's been<br />modified to "the text of the GPL license plus an additional clause<br />which is that if you want to use this for commercial purposes then...<br />you can't". which is *NOT* a GPL license, it's a proprietary<br />commercial license!<br /><br />MIAOW is just an OpenCL engine but a stonking good one that's<br />compatible with AMD's software.  nyuzi is an experimental GPU where i<br />hope its developer believes in its potential.  ORGFX i am currently<br />evaluating but it looks pretty damn good, and i think it is slightly<br />underestimated.  i could really use some help evaluating it properly.<br />my feeling is that a combination of MIAOW to handle shading and ORGFX<br />for the rendering would be a really powerful combination.<br /><br />so.<br /><br />it's basically doable.  comments and ideas welcome, please do edit the<br />page to keep track of notes <a href="http://rhombus-tech.net/riscv/libre_riscv">http://rhombus-tech.net/riscv/libre_riscv</a>/<br /><br />---<br />crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68">https://www.crowdsupply.com/eoma68</a><br /><br /><hr /><br />arm-netbook mailing list arm-netbook@lists.phcomp.co.uk<br /><a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a><br />Send large attachments to arm-netbook@files.phcomp.co.uk</pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>