[J-core] 2 CPU:s or nothing

[Rob Landley]

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?

If by MCU you mean microntroller instead of marvel cinematic universe,
you can have a J1 and a J2 instance at the same time, sure. I suppose it
might be a little like the big.little stuff the arm guys are doing, but
that always struck me as overcomplicated.

> Is Linux capable of low latency stuff?

Its interrupt path appears to take about 9000 clock cycles to context
switch, so at these clock speeds? Not so much.

> Or do you use a FPGA for that?

Our chip can run in an FPGA, or as an asic. I'm not sure what you're asking?

> So if you use a ASIC with j-core, do you then need 1ASIC, 1FPGA 1MCU?

You don't "use an ASIC with j-core", you have an ASIC implementation of
jcore. Same as "you don't use an arm with linux", you have a linux
binary built for arm. It's the output format of the tools...

> Why is than that ASIC needed, and why is that FPGA needed?

To do _what_?

> 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?

You're the one who proposed having the separate MCU in the first place?

> Maybe that ASIC could have 1MCU and 1CPU.

Maybe it would have 3 of each and a sound card too?

> 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.

And a USB controller and two blinky lights on it?

> That MCU can then be used to
> patch the holes that Linux has on the real-time side.

You could strap model rocket engines to them and light it. You could
wire it up to your car's stereo system. You could hang it from a
christmas tree. All of these have approximately as much context.

You haven't specified what you're trying to do and how.

> 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.

The one you proposed using in the first place? Maybe. (I assume you mean
toolchains. Is having different toolchains a high bar? My aboriginal
linux project had a dozen or so, and I've built something like 8 targets
with Rich's musl-cross-make.)

> Maybe that wouldn't be space efficient, but is that really a concern.

A concern for what? While doing what? Trying to accomplish what?

> 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,

In _which_ ASIC? We have a boot rom in our FPGA SOC design, but an SOC
and a processor aren't the same thing.

> and then be load new programs into RAM.

Usually that's what a boot rom does, yes?

> That wouldn't be efficient but cheep, and give fewer tool chains,
> and a lot easier to design things with that ASIC later on.

Usually general purpose processors are capable of running programs out
of RAM, yes.

https://en.wikipedia.org/wiki/Stored-program_computer#History

> Building a ASIC is a bit confusing.

Not so much confusing as complicated, but Jeff's done it before.

It turns out the real problem is every fab's synthesis toolchain is
different (imagine all compilers had proprietary code backends, each for
different processor architectures), and each "test compile" you run
costs tens if not hundreds of thousands of dollars. So you need 8
gazillion unit tests for tiny pieces of the thing, and you need to
confirm that what the synthesis tools produced actually produces all the
same input and output values you expect it to.

Kinda like having exhaustive unit tests for every function in a C
program, all the possible range of inputs and outputs you care about.

> 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.

Or you could make it small and simple and general purpose, and _not_
glue on every weird thing people might want. (Just a thought.)

> It would cost more for that first application.

Yes. Yes it would.

> But is really
> the ASIC the cost split over the number of pieces,

Power consumption isn't. Trace length and thus clock speed at which you
can run it isn't. And there's opportunity cost of higher-way normal SMP,
or more SRAM on the chip, or more DSPs, or more DMA engine instances, or
multiple DRAM controller instances so you could hook up more DRAM...
(Our turtle build has HDMI and USB controller plumbing...)

> than maybe that separate MCU should be dumped.

The one you and only you proposed having in the first place?

> 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.

Jeff has built multiple projects that actually shipped before. The last
ASIC he fabbed was a year ago. I'm happy to trust his judgement on this
sort of thing.

> It would
> draw people to that platform, instead of away from it, because it does
> not have any practical applications for them.

You're saying we could make an ASIC that would draw people _away_ fro
the platform, rather than simply being ignored?

You're aware there are things called multi-project wafer services where
students and such can produce low-volume asics without committing to a
large fab run? (The per-chip cost is ridiculous, but it lets you
prototype physical chips for a few thousand dollars.)

https://en.wikipedia.org/wiki/Multi-project_wafer_service

An ASIC version _existing_ it not actually that high a bar.

Rob