<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-04-27 13:21 GMT+02:00 Luke Kenneth Casson Leighton <span dir="ltr"><<a href="mailto:lkcl@lkcl.net" target="_blank">lkcl@lkcl.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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/" rel="noreferrer" target="_blank">http://rhombus-tech.net/riscv/<wbr>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" rel="noreferrer" target="_blank">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></blockquote><div><br></div><div>Perhaps put it sirectly to an USB bridge. UART's on debugging hardware is non existant. We all use FTDI dongles.</div><div><br></div><div>Look like OpenCores has a module. <a href="https://opencores.org/project,usb2uart">https://opencores.org/project,usb2uart</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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/" rel="noreferrer" target="_blank">http://rhombus-tech.net/riscv/<wbr>libre_riscv/</a><br>
<br>
---<br>
crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" rel="noreferrer" target="_blank">https://www.crowdsupply.com/<wbr>eoma68</a><br>
<br>
______________________________<wbr>_________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" rel="noreferrer" target="_blank">http://lists.phcomp.co.uk/<wbr>mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a></blockquote></div><br></div></div>