[J-core] 2 CPU:s or nothing

[BGB]

On 11/25/2016 12:04 PM, Daniel V wrote:
> Hi!
>
> Ok, some philosophical stuff here. And not critique of any kind.
>
> I just want to remind about something...
>
> If you want to boot a system you have a MCU and a CPU. Why cant both
> be built upon j-core?
>
> Is Linux capable of low latency stuff? Or do you use a FPGA for that?
> So if you use a ASIC with j-core, do you then need 1ASIC, 1FPGA 1MCU?
> Why is than that ASIC needed, and why is that FPGA needed? I
> understand if you want to build a custom platform that you can dump
> that FPGA and separate MCU, but it would be highly specific. But why
> not make it more general?
>
> Maybe that ASIC could have 1MCU and 1CPU. And why not let that MCU
> have 2 memory blocks, A boot-loader, and a separate memory for loading
> Arduino sketches or stuff like that. That MCU can then be used to
> patch the holes that Linux has on the real-time side.
>
> Maybe it's possible to reduce the need of the number of development
> chains to a fewer number, by letting that MCU be built upon a J-core.
> Maybe that wouldn't be space efficient, but is that really a concern.
> It's a lot cheaper than to have a separate of the shelf MCU and board
> space for it. If that MCU built upon J-core you could have a masked
> boot ROM in the ASIC, and then be load new programs into RAM. That
> wouldn't be efficient but cheep, and give fewer tool chains, and a lot
> easier to design things with that ASIC later on.
>
> Building a ASIC is a bit confusing. Because inefficient things is
> cheep. I'm not promoting bad design. I'm promoting flexibility by
> extending the thought a bit longer, and realize that extended
> capability will save money and time later on and give a longer
> usability of that ASIC, for other loads of projects by making it more
> general. It would cost more for that first application. But is really
> the ASIC the cost split over the number of pieces, than maybe that
> separate MCU should be dumped.
>
> I'm not saying that this is what to do, I'm saying that it's a thought
> that may come in handy for building upon a possible future. It would
> draw people to that platform, instead of away from it, because it does
> not have any practical applications for them.

something with both 1 or 2 CPU cores and an MCU could be nice.

possibly, the MCU's address space and also IO peripherals are exposed as 
a memory-mapped IO device, then the CPU can send a program over to the 
MCU part and let it run, possibly with the MCU being entirely RAM, 
rather than the usual SRAM+Flash (idea being here that the CPU loads a 
program into it on startup).

maybe also they can send interrupts to each other, to help facilitate 
passing messages between the CPU and MCU (with a pointer used to 
indicate where the message is at).

possibly both the CPU and MCU could have access to the GPIO pins and 
similar.

possibly, the MCU part could use a more limited form of the SH ISA 
if-needed to save transistors. for example, a lot of MCUs I have seen 
omit having things like a hardware multiplier. I guess relevant could be 
seeing what is the minimal set of features (presumably unmodified) GCC 
needs to make working code.



otherwise, yeah, not been doing much here lately, have been off working 
on other unrelated stuff, mostly on a newer Minecraft-style voxel 
engine. not much directly relevant, but misc stuff:
specialized LZ77+Rice entropy coder (mostly as a lower-overhead 
alternative to Deflate);
ended up inventing a vec3 format which stores 3 extended-floats in 128 
bits (last 32 bits is divided up and used as to extend the mantissa 
fields of the first 3 floats), mostly because the world-size is too big 
for normal float32 coords to be sufficient (but saved effort over adding 
3x double vectors to the script VM).

as noted, the C compiler idea basically stalled out and didn't go very 
far, and what work I was doing on the script VM was mostly used for the 
3D engine.

TBD if I will do more on the emulator.