[J-core] 2 CPU:s or nothing
daniel.viksporre at gmail.com
Fri Nov 25 22:41:44 EST 2016
2016-11-26 0:09 GMT+01:00, Rob Landley <rob at landley.net>:
> On 11/25/2016 12:04 PM, Daniel V wrote:
>> 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.
Well that was not what I was talking about. That they are trying to
do, is reducing power consumption.
>> 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
If you don't understand what people are tanking about, why are you
basing your following rant on this?
I rhetorically implied that linux isn't suitable for real-time stuff.
If you need real-time what do you use then? Use a separate MCU? A
separate FPGA? That was what I was tanking about.
What I was implying is that a built in MCU could be used to handle
>> 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...
I was talking about when you make an ASIC with one j-core in it.
>> Why is than that ASIC needed, and why is that FPGA needed?
> To do _what_?
To do real-time stuff. Maybe it was not clear, but the question about
if Linux was capable of real-time was rhetorical.
And i suggested a extra j-core with RAM, to get rid of an external MCU
for real-time i/o and thinks like that.
But if those DSP's has I/O capability that wouldn't be 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?
> You're the one who proposed having the separate MCU in the first place?
I was implying that a MCU is in many applications needed for real-time
stuff, you can have that MCU inside the ASIC instead. If someone don't
need that, it's their application. I don't condone it.
>> Maybe that ASIC could have 1MCU and 1CPU.
> Maybe it would have 3 of each and a sound card too?
It is was to make real-time things and use a j-core as a MCU. I was
talking about reducing the number of parts, not adding to it. You are
the one talking about adding things.
But a 2 channel DAC and ADC with signed data is not wrong. Do you have
anything specific against DSP applications and real-time?
>> 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?
What has blinky lights to do about this? To implement your hello world examples?
>> 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.
Linux don't necessarily have real time capabilities has it? It's a
well known problem.
>> 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.)
Yes, my main language isn't English.
But does it have a tool-chain for AVR or PIC and things that isn't
linux? If not, then that was what I was talking about. If you need a
MCU in your project, then you will need a tool-chain for that. I what
I suggested was a way to get rid of that. If possible you probably
avoid linux for real-time in some cases for cost reduction, and to
lower power consumption.
>> Maybe that wouldn't be space efficient, but is that really a concern.
> A concern for what? While doing what? Trying to accomplish what?
To accomplish real-time applications by offloading a CPU running
Linux. The context switching in linux would take more power and gain
poor results, than using one extra core with a small amount of RAM.
>> 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.
I was talking about if anyone were to make an ASIC. And that it would
be an idea to have a MCU built into that ASIC it to do real-time
>> and then be load new programs into RAM.
> Usually that's what a boot rom does, yes?
I was talking about loading a program with that MCU, and then use that
MCU for real-time handling.
>> 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.
Well??? What point are you trying to make??? That you didn't
understand what I was going to talk about with that rhetorical
question about linux real-time capabilities?
>> Building a ASIC is a bit confusing.
> Not so much confusing as complicated, but Jeff's done it before.
Well, that was obviously not what I was talking about. I was talking
about cost and complexity reduction.
> 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
> Or you could make it small and simple and general purpose, and _not_
> glue on every weird thing people might want. (Just a thought.)
Well I was talking about a way to make things simpler and more general
purpose, and gain real-time performance.
>> It would cost more for that first application.
> Yes. Yes it would.
But would cost less later on when you have your ASIC. And that was the
point I was making.
It's good to don't get carried away trying to reduce the IC cost from
60 cents to 40 cents. In these cases, the IC itself may constitute a
small part of the total product's cost, so it doesn't matter what the
IC cost to produce.
Don't get carried away dreaming of just how small and cheep the part
can possibly be, as this may result in smaller wafer purchases, for a
more modest market, and may drive the price up.
>> 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...)
A external MCU take power also. And logic in a ASIC just take leakage
current if you don't clock it. And you only need a slow clock on that
MCU logic, to outperform linux regarding real-time. And trying to do
this all in one core running linux, is a waste of power.
>> than maybe that separate MCU should be dumped.
> The one you and only you proposed having in the first place?
Well real-time performance require it. Or if you need something even
faster, you use a FPGA, and even faster you use an ASIC with hard
logic for it.
>> 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.
Well I was not telling any one what to do.
>> 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?
Well if people think that they don't have any use for it, when they
would stop considering using it. But ignoring it, would be a way to
> 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.)
Well I'm well aware of that.
That also points out that there is a good reason for higher volumes,
and be able to reuse your design or sell chips to others.
I was not trying to say what someone should do. It was philosophic
reasoning, about implications around Linux incapabilities in real-time
If anyone want a lower cost ASIC, a MLM design is an alternative where
four masks is placed onto a single mask.
> An ASIC version _existing_ it not actually that high a bar.
More information about the J-core