On Mon, Jun 25, 2018 at 3:03 PM, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:

BTW: As we've already determined in our Mumble sessions (with more than one lawyer giving us the same answer): The GPL does not cover tape-outs.

that's... interesting.

On Mon, Jun 25, 2018 at 4:28 PM, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:

of our logic cells and layout methodologies as "Gebrauchsmuster" [1].

that sounds a lot like "Design Rights". l.

Shit Autocorrect in the worst....!!!!! Wahhh I mean dear friend not dead friend... ^^' He's very much alive of course! Just got my mail into!!! Sorry again! On Tuesday, 26 June 2018 12:37:54 AM HKT David Lanzendörfer wrote:

Hi

...

that sounds a lot like "Design Rights".

-> "Geschmacksmuster (German industrial design right)" Yes it is design right.

With that we make it possible to cover the details of what happens with a design when manufactured. Something the GPL doesn't cover even remotely.

It's a legal hack in order to make the license expand into territories no other free license has expanded into so far. We're lucky to have a very gifted lawyer with us on board (Cedric, dead friend and co-founder of the company) who has studied law in the university Beijing and knows Chinese law very well. With the support of some of his friends and some lawyers from Germany we're close to finalizing our new license which is applicable in every country by making use of legal constructs like the "design right".

Cheers David

-- Best regards CEO, David Lanzendörfer Lanceville Technology 22A, Block2, China Phoenix Mansion, No.2008 Shennan Boulevard, Futian District, Shenzhen

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Jun 25, 2018 at 5:44 PM, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:

Shit Autocorrect in the worst....!!!!! Wahhh I mean dear friend

!!! :)

On Mon, Jun 25, 2018 at 6:21 PM, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:

Hi

...

crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 We've discussed this project yesterday and I strongly suggested to get you on board for layouting high-frequency PCBs in case we need to do a demo FPGA board for your customers. Because you've got the experience from the EOMA board project.

yes i can handle high-speed differential-pairs, now, i know the rules about doing proper impedance matching, and how to create the clearance rules. also i can happily do power-tracks (PMICs), and general layout, no problem. what i *can't* do is DDR3/DDR4 layouts. or, i can... but you should expect it to take several months and require several iterations. really *really* good people cost around $5k-$10k in china and they can do DDR3 layouts in about 3 weeks flat. the absolute absolute best teams have access to ultra-expensive simulation software that's specially designed to check DDR3/DDR4 layouts. they're... hell, frankly. DDR4 has got to the point where the length of the bond-wires and the layout of the PCB *inside the fucking chip* has to be taken into account. l.

On Mon, Jun 25, 2018 at 6:37 PM, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:

Hi As it happens: We're in China and have access to these folks you've mentioned. But careful! Salaries here a raising continuously here so it might be not as cheap as you might expect either.

i know. the facttory's already moved out to dongguang, several companies are moving even further. some people are moving as far as zhuhai however with the HK-Zhuhai road bridge coming online property developers are speculative-buying and it's going mental.

Anyway. I'm working on getting a basic SoC wired together right now with all the essentials inside, so that we can test to boot up a Linux with HDMI output on a RISC-V.

cool. vga_lcd. https://github.com/RoaLogic/vga_lcd - richard's updated it. many FPGA dev boards have an RGB/TTL-to-HDMI converter IC on board (TFP410 or equivalent). l.

David Lanzendörfer schreef op di 26-06-2018 om 03:06 [+0800]:

Manili is talking with the guy who created the NyuziProcessor.

We will most likely just boot a firmware on a multi-core GPU-system and will then be able to define the kind of platform with jumpers or alike. A jumper code for how many HDMI/DVI/VGA ports there are.

I'm sorry guys I can't follow, but are you guys talking about a multi- core system + GPU in the 1um process you guys try to get from the ground ? greets, Staf.

On Tuesday, 26 June 2018 4:06:38 AM HKT Hagen SANKOWSKI wrote:

Well, we are talking about different points on the timeline.

At first, of course, comes the 1um technology with test wafer. But our next step is already a small Microcontroller, eg. the RISC-V 32E favour, with some usefull peripherials.

While our technology node gets smaller, we like to present a complete free and open System-on-Chip with GPU. So this is more a mid-term goal.

Exactly

On Mon, Jun 25, 2018 at 9:06 PM, Hagen SANKOWSKI <hsank@posteo.de> wrote:

At first, of course, comes the 1um technology with test wafer. But our next step is already a small Microcontroller, eg. the RISC-V 32E favour, with some usefull peripherials.

if you'd like it to be a commercially successful chip, you will need - without a shadow of doubt - a pinmux. a pinmux allows a chip to be targetted at multiple simultaneous markets at a reduced package cost, by permitting software-controlled redirection of up to four times (or even eight times if you are Texas Instruments) as many peripherals as there are actual physical pins on the chip. by targetting multiple markets the chip sells more units. by selling more units the quantities increase. by increasing the quantities the foundries have time to tune the fab in order to increase yields. by increasing yields the price of the chip comes down. by decreasing the price, the chip sells more units. if you're not familiar with what a pinmux is, here are some resources: http://bugs.libre-riscv.org/show_bug.cgi?id=8 hands.com/~lkcl/pinmux_chennai_2018.pdf https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf http://libre-riscv.org/shakti/m_class/pinmux/ http://git.libre-riscv.org/?p=pinmux.git;a=summary please note: a *commercially viable* 100% completed libre pinmux does NOT EXIST. SiFive's IOF is *NOT* suitable for general-purpose use (it does not do priority in-muxing). l.

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Jun 26, 2018 at 5:15 AM, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:

...

if you're not familiar with what a pinmux is, here are some resources:

http://bugs.libre-riscv.org/show_bug.cgi?id=8 hands.com/~lkcl/pinmux_chennai_2018.pdf https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf http://libre-riscv.org/shakti/m_class/pinmux/ http://git.libre-riscv.org/?p=pinmux.git;a=summary I'm familiar with pinmuxing :-)

good. other people on the list may not be.

...

please note: a *commercially viable* 100% completed libre pinmux does NOT EXIST. SiFive's IOF is *NOT* suitable for general-purpose use (it does not do priority in-muxing). Mohammed from eFabless promised me to put Tim (also on this list) and the others at the problem as soon as we get there. eFabless will design us a LibreSilicon muxing pad cell, which will essentially be a big analog switch with multiple contacts wired to of which only one is analog switched out at a single time.

it's a lot more complex than it seems: designing a pinmux is deceptive. a bit like how designing a DRAM cell is real easy so surely doing a DDR3/4 chip should be easy too, right? the case that most people forget about is the one-pin to many-inputs case, which is absolutely essentlal to cover for a commercially successful chip (and with SiFive avoided dealing with by only ever having one-to-one on the inputs). see slides 23 to 25 for why a priority-input mux is needed: http://hands.com/~lkcl/pinmux_chennai_2018.pdf the pad characteristics *do not* need to be multiplexed. however the in, out and direction control *do* need to be multiplexed. (see slide page 14). also it is *not* necessary to design an analog switch (and it is actually severely problematic for the rest of the design, to do so, as the entire chip must now be treated 100% as an analog design): a digital-only design can be done (and will cause a hell of a lot less problems). also as shown in the ericsson slides, it isn't necessary to do tri-stating either (except obviously as part of the IOpad control and characteristics, which themselves are *not* multiplexed). basically a standard single-input single-output flexibly-configurable IO cell is sufficient for the job: one where it can be switched from Open-Drain to CMOS Push-Push, its pull-up and pull-down resistors can be enabled/disabled, hysteresis can be controlled, its current can be controlled, and so on. see STM32 Technical Reference Manuals (any one will do) and libopencm3 for details on what the pad characteristics look like. based on that single-input single-output flexibly-configureable IO cell a COMPLETELY INDEPDENDENT external (*entirely digital design*) pinmux that HAS NOTHING TO DO WITH IO cells can be dropped on top of it, with no difficulty, and get the job done with no loss of functionality or compromises. see slides 14-17 for details. l.

On Tue, Jun 26, 2018 at 7:46 AM, Hagen SANKOWSKI <hsank@posteo.de> wrote:

Good Morning.

morning, hagen.

On 06/26/2018 07:56 AM, Luke Kenneth Casson Leighton wrote:

Well, it is my part to design the Standard Cell Library for our LibreSilicon technology, as soon as I get the test wafer structures in Silicon. I already designed cells years ago.

excellent.

Luke, please provide me the cells you would like to get - I'll do what is possible.

that's great to hear. the strategy i was advised of by people on the librecores list summarised ass: keep the IO cell absolutely standard (which basically means an analog design), and keep the muxing separate (and entirely digital). attached is an example diagram. there's only one thing missing from it and that's the current control selection. apart from that it's identical to (based on) the elinux.org ericsson IO cell diagram (link sent already, previous message). here is a list of requirements: * pull-up control which switches in a 10k (50k?) resistor * pull-down control which switches in a 10k (50k?) resistor * a "mode" setting that flips it between Open-Drain (floating if LO, and pulled to GND if HI) and CMOS (MOSFET) Push-Push modes. see https://en.wikipedia.org/wiki/Open_collector#MOSFET for details on Open Drain (requires a MOSFET). * a "hysteresis" setting that controls the input schottky filter's sensitivity. this is important for push-buttons for example, to stop spiking (bounce) that would be amplified and result in massive noise spikes onto all wires throughout that entire area of the chip. low middle and high settings are needed to cover filtering ranges of say 2mhz, 5mhz, 10mhz and unlimited (disabling hysteresis). looking at STM32F documentation helps here as does this https://electronics.stackexchange.com/questions/156930/stm32-understanding-g... * an input-enable selector * an output-enable selector * also required is a means to change the current output: 10mA, 20mA, 30mA and 40mA are reasonable * also the input and output really need *automatic* level-shifting, built-in to the IO cell. so whilst there is a VDD for driving the pad (and setting the CMOS threshold levels for input), there is *also* a need for an IO VREF. this is *important*. the input and output needs to be CMOS push-push (standard logic) whilst the IO pad needs to be switchable between OD and PP. * input threshold voltages that trigger the input from HI to LO should be standard CMOS voltage levels (even in OD mode), which i believe is below 0.3 * VDD for "LO" and 0.7 * VDD for "HI" * output voltage levels should be as close to 0 as possible for LO (0.3v or below @ nominal temperature) and as close to VDD as possible for HI (VDD-0.3v or above @ nominal temperature). * some ability to protect itself from over-driving (current fights) when in output mode are a must. * the ability to protect itself from *being* over-driven when in input mode is not strictly necessary (over-voltage tolerance e.g. 5V tolerance when VDD is well below that) but would be nice to have as an option (two variants: one for ECs which need 5V tolerance and one for SoCs where it's not).

BTW, we already talked same years back in Brussels at FOSDEM about your great EOMA86 idea. I really like it :-) Keep going!

thanks :)

So, do you like to provide us (or me?) a list of requirements / features your embedded SoC really needs, which are nice to have and which are to avoid?

documented here: http://libre-riscv.org/shakti/m_class/ i need to update it as i've managed to track down an LPDDR3 PHY (USD $300k), and also HyperRAM (upcoming JEDEC xSPI).

Please dream, speculate, write down the list for the free and open silicon variant of your modules.

all documented on that page (see "Interfaces" sections), with full links to libre-licensed HDL that i've been able to find (which is most of them: eMMC is missing, and i'd like to do USB2 PHY rather than have three ULPI/UTMI interfaces). the top-level bugtracker entry tracking them is here: http://bugs.libre-riscv.org/show_bug.cgi?id=2

And yes, I like to put in this card into my next "Brotkasten"-Style [0] laptop and developing the next generation even on this laptop.

cool :)

I think, with getting this numbered list, we can great cooperating, even for dedicated IO Cells, RAMs and so on. do not hesitate.

awesome. the project that i'm working on needs a 512 mbyte DRAM, to be made in a minimum of 110nm (which is where you can get up to 400mhz double data-rate). twin 128 mbyte DRAMs would do fine, as probably would four 64 mbyte DRAMs (in a pinch). i have been promised (free, monetarily-zero-charge) access to a university's 180nm foundry *IF* and *ONLY* if the entire design is libre. if you can design a DRAM that can be tested for tape-out on 180nm which has a HyperRAM interface i *might* be able to justify putting it to the sponsor. could you give me some idea of the die area that a 512mb DRAM would take up, say, in 110nm? and is the size dependent on geometry at all? some cells are not (you can't shrink IO pads for example, no matter what geometry), but i don't know enough about DRAM design (other than, "it's a capacitor" and a transistor) l.

Hello Luke. On 06/26/2018 09:26 AM, Luke Kenneth Casson Leighton wrote:

the strategy i was advised of by people on the librecores list summarised ass: keep the IO cell absolutely standard (which basically means an analog design), and keep the muxing separate (and entirely digital).

Yes, of course.

there's only one thing missing from it and that's the current control selection.

I'll put it on my list, probably a little bit harder than all the other points.

identical to (based on) the elinux.org ericsson IO cell diagram (link sent already, previous message). Common standard.

here is a list of requirements:

* pull-up control which switches in a 10k (50k?) resistor

* pull-down control which switches in a 10k (50k?) resistor

low-hanging fruits

* a "mode" setting that flips it between Open-Drain (floating if LO, and pulled to GND if HI) and CMOS (MOSFET) Push-Push modes. see https://en.wikipedia.org/wiki/Open_collector#MOSFET for details on Open Drain (requires a MOSFET).

also easy, I'll put it on the list.

* a "hysteresis" setting that controls the input schottky filter's sensitivity. this is important for push-buttons for example, to stop spiking (bounce) that would be amplified and result in massive noise spikes onto all wires throughout that entire area of the chip. low middle and high settings are needed to cover filtering ranges of say 2mhz, 5mhz, 10mhz and unlimited (disabling hysteresis). looking at STM32F documentation helps here as does this https://electronics.stackexchange.com/questions/156930/stm32-understanding-g...

Hysteresis is mostly done a slighter other way than a filter - a small google search got me this picture http://farhek.com/jd/z1158t7/hysteresis-in/97kl85/ with the typical transistors controlled by the output signal. The reason for that is, that analog stuff like resistors and capacitors always taking to much area and are liked to be replaced by smaller sized transistors. Filters are ugly in silicon.

* an input-enable selector

* an output-enable selector

Always on the list.

* also required is a means to change the current output: 10mA, 20mA, 30mA and 40mA are reasonable

* also the input and output really need *automatic* level-shifting, built-in to the IO cell. so whilst there is a VDD for driving the pad (and setting the CMOS threshold levels for input), there is *also* a need for an IO VREF. this is *important*. the input and output needs to be CMOS push-push (standard logic) whilst the IO pad needs to be switchable between OD and PP.

This comes to the list as soon as our technology node gets smaller. Currently we plan 1um with 5 Volt only. But next node with 0.5um should handle 5 Volt as 3.3 Volt. And so we do need this IO-Banking concept I am very familiar with from FPGAs.

* input threshold voltages that trigger the input from HI to LO should be standard CMOS voltage levels (even in OD mode), which i believe is below 0.3 * VDD for "LO" and 0.7 * VDD for "HI"

Agree.

* output voltage levels should be as close to 0 as possible for LO (0.3v or below @ nominal temperature) and as close to VDD as possible for HI (VDD-0.3v or above @ nominal temperature). Agree, only one (big) transistor between output and power rails - the Drain-Source-Voltage in a switched state should be very small.

* some ability to protect itself from over-driving (current fights) when in output mode are a must.

naturally

* the ability to protect itself from *being* over-driven when in input mode is not strictly necessary (over-voltage tolerance e.g. 5V tolerance when VDD is well below that) but would be nice to have as an option (two variants: one for ECs which need 5V tolerance and one for SoCs where it's not).

This topic and the topic before are aware by the ESD protection stuff.

...

So, do you like to provide us (or me?) a list of requirements / features your embedded SoC really needs, which are nice to have and which are to avoid?

documented here:

http://libre-riscv.org/shakti/m_class/

i need to update it as i've managed to track down an LPDDR3 PHY (USD $300k), and also HyperRAM (upcoming JEDEC xSPI).

I'll keep an eye on this new hyped HyperRAM.

the project that i'm working on needs a 512 mbyte DRAM, to be made in a minimum of 110nm (which is where you can get up to 400mhz double data-rate). twin 128 mbyte DRAMs would do fine, as probably would four 64 mbyte DRAMs (in a pinch).

Any RAM, in principle, is a good technology driver while containing big regular structured areas. Do you now this https://github.com/VLSIDA/OpenRAM/blob/master/OpenRAM_ICCAD_2016_paper.pdf paper here? Just layout your cell primitives and all the stuff for completing the RAM is generated by this script. Doing so is a common thing, new is that the generator itself is published and not NDA'ed by a "solution partner firm". I think, we can do design our small cells also. But this is on the longer To-Do-List, as we need RAM for caches etc.

i have been promised (free, monetarily-zero-charge) access to a university's 180nm foundry *IF* and *ONLY* if the entire design is libre. if you can design a DRAM that can be tested for tape-out on 180nm which has a HyperRAM interface i *might* be able to justify putting it to the sponsor.

Until now I do not have experience with 180nm, so I am a little bit hesitating. Do you have more details for that? I understood this is a Europractice or Mosis Multi-Project-Wafer submission, isn't it? Okay, about which time schedule we are talking?

could you give me some idea of the die area that a 512mb DRAM would take up, say, in 110nm? and is the size dependent on geometry at all? some cells are not (you can't shrink IO pads for example, no matter what geometry), but i don't know enough about DRAM design (other than, "it's a capacitor" and a transistor)

Roughly spoken, the textbooks missing the back-stage details. Yes, the storage cell itself "it's a capacitor". But the logic around, driving long lines for reading / writing / refreshing are analog art close to Voodoo (randomly mentioned in some details by textbooks). And there are huge analog amplifier beside all the digital stuff like address logic, build-in-self-test, refresh-logic, interface logic etc. IMHO the back-stage stuff takes at least 20% of the core logic area. And yes, the IO cells are in-flexible in shrinking sizes. So, I guess, 50% of the die-size is fixed at all. Let's calculate: a 1-bit cell in 110nm would take - let's say - .5 by .5 um, multiplied with 512M (aka 536870912 cells) is 134217728 square microns. Doubled for back-stage stuff and IOs means 268435456 square microns at all - this are round about 16 x 16 mm if I am not completely wrong. Oh my god, this is huge! Okay, back from break, I got a good impression, where the problems are - size matters! Challenge accepted! Hagen

Hi

as mentioned previously i have been told by a university that they are happy to put forward libre (and only libre) designs into actual silicon at zero charge. it's a 180nm fab. It's basically the same then as we have here in Hong Kong. A lab where they can run a process manually. As soon as we've got verified our process with 1um on the HKUST machines, they can try to set it up with their machines. We can actually go down far below 180nm here by using nano-imprint stamps. The question is more about the geometry required to produce working circuits at these sizes... If that university is interested into joining the #LibreSilicon project and help with the R&D they're welcome.

Cheers David

Hi people, Pinmuxes are dangerous, because they sometimes mux the wrong thing like having 2 differential pins one could choose between usb or sata. If one wants both?! Many SOCs I encountered work like this. Such pain should be avoided. A pinmux needs proper planing. Go for a large package with a good socket and have not too much need to mux, as if it is done extremely one could end in a castrated system. I would suggest to use old Intel sockets as the ZIF-Sockets are in the wild and the package manufacturers also produce them. Cheers, Ludwig On 06/26/2018 12:15 AM, David Lanzendörfer wrote:

a pinmux. a pinmux allows a chip to be targetted at multiple simultaneous markets at a reduced package cost, by permitting software-controlled redirection of up to four times (or even eight times if you are Texas Instruments) as many peripherals as there are actual physical pins on the chip.

by targetting multiple markets the chip sells more units. by selling more units the quantities increase. by increasing the quantities the foundries have time to tune the fab in order to increase yields. by increasing yields the price of the chip comes down. by decreasing the price, the chip sells more units.

Hello. On 06/27/2018 09:47 AM, Luke Kenneth Casson Leighton wrote:

On Wed, Jun 27, 2018 at 5:23 AM, Ludwig Jaffe <ludwig.jaffe@gmail.com> wrote:

...

Hi people,

Pinmuxes are dangerous, because they sometimes mux the wrong thing like having 2 differential pins one could choose between usb or sata. If one wants both?!

that's precisely why i am not muxing USB or SATA. SATA because they require specialist IO pads with voltage reference levels way WAY different from standard GPIO.

Assume that all this hiqh-speed busses using dedicated IO cells. As we are talking about muxing, this belongs to more-or-less standard CMOS/TTL leveled signals - no differential, no MIPI (with extra small swing), no SERDES signals (USB, SATA, Gbit Ethernet, RIO,..)

basically a pinmux is good for low-speed *digital* signals up to around 200mhz, possibly 300mhz if you're really lucky.

Assume a cut-off frequency (-3dB) of roundabout 150 MHz on Pads.

...

Many SOCs I encountered work like this.

Many SoC and FPGA do have "configurable" GPIO IO-Banks for that.

...

Go for a large package with a good socket and have not too much need to mux,

Assume, that the package itself takes roughly 90% of the total chip cost. Reducing the complexity / pincount also reducing the cost. Large packages are a pain in the ass, just mostly using for having more pins for power and ground available.

also you cannot fit a 1,200 pin chip of size 40mm x 40mm onto a PCB of size 38 x 50mm.

...

I would suggest to use old Intel sockets as the ZIF-Sockets are in the wild and the package manufacturers also produce them.

the socket alone will cost about the same or possibly even more than the SoC, even in mass-volume quantities.

@ludwig: The reason why we have now ball-grid arrays instead of real pins is the cut-off frequency for that old-style pins, which is quite lower than for ball-grids. Extra sockets are extra pain. Did you know, that for high-speed memories now the internal bond-wire has to taken into account of calculating the delay (for getting the proper sampling time point) on PCBs?

i'm developing a $3 to $4 15x15mm 3W SoC, ludwig, not a $500 intel 150W completely impractical billion-transistor chip with a sale price of over $500.

Yes, an this chips has to fit together with a couple of another chips into the EOMA86 housing, known from PCMCIA cards. Regards, Hagen Sankowski

Hi Ludwig I see it the same way. For the MCU will have to do muxing however, because we wanna ship it in a DIP package compatible to the ATMega series in order to plug them into Arduino boards essentially. (Making the upgrade of legacy systems easier) For the SoCs we will use a BGA layout with flip chip bond and yes, that's exactly what I had in mind. Something like the socket system from Intel. Cheers David On Wednesday, 27 June 2018 12:23:48 PM HKT Ludwig Jaffe wrote:

Hi people,

Pinmuxes are dangerous, because they sometimes

mux the wrong thing like having 2 differential pins one

could choose between usb or sata. If one wants both?!

Many SOCs I encountered work like this.

Such pain should be avoided. A pinmux needs proper planing.

Go for a large package with a good socket and have not

too much need to mux, as if it is done extremely one could

end in a castrated system.

I would suggest to use old Intel sockets as the ZIF-Sockets are

in the wild and the package manufacturers also produce them.

Cheers,

Ludwig

On Mon, Jun 25, 2018 at 8:06 PM, David Lanzendörfer <david.lanzendoerfer@o2s.ch> wrote:

Hi Manili is talking with the guy who created the NyuziProcessor.

jeff's extremely knowledgeable. he'll learn a lot. manili you should really begin by reading jeff's posts: https://jbush001.github.io/

We will most likely just boot a firmware on a multi-core GPU-system and will then be able to define the kind of platform with jumpers or alike. A jumper code for how many HDMI/DVI/VGA ports there are.

the SoC that i'm tasked with getting done will not be a stand-alone GPU, it will be a shared memory bus architecture. the power budget and size budget is far too small to do anything like a separate GPU chip with GDDR5 memory. in that architecture adding HDMI or other ports specifically connected to the GPU is both completely out of the question and totally unnecessary. in this architecture, which is 100% standard across the industry for SoCs, all that the GPU needs to do is write to an area of memory (framebuffer or area of the framebuffer). the SoC - which in this case has a RISC-V core and has peripherals such as the LCD controller - will take care of the rest. in this arcitecture the peripherals, the GPU and the CPU are all on the same AXI4 shared memory bus, they all have access to the same shared DDR3/DDR4 RAM. l.