[J-core] 2 CPU:s or nothing
rob at landley.net
Sat Nov 26 13:40:32 EST 2016
On 11/25/2016 09:41 PM, Daniel V wrote:
> 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.
The two processors can run at the same time, and don't have to run the
same code. Qualcomm's Snapdragon SOC in most android phones has 4
different processors in it, only one of which runs Linux. (Although I
helped port Linux to the hexagon, but that's not what's running in the
So yes, hardware like that exists. Programming it in new ways is your
>>> 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?
If "I don't understand what you mean" offends you, I can stop replying
> I rhetorically implied that linux isn't suitable for real-time stuff.
Is that what you were doing?
> If you need real-time what do you use then? Use a separate MCU? A
> separate FPGA? That was what I was tanking about.
Jeff wants to use https://github.com/rtmux/rtmux
> What I was implying is that a built in MCU could be used to handle
> real-time events.
We have DSPs and we have SMP. You want a third kind of processor because...?
>>> 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.
I believe the ASIC we're currently looking at would be 2-way SMP,
>>> 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.
That was not clear to me, no.
> 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.
It's already SMP. You can run Linux on one processor and run something
else on the other processor _today_ if you want to.
(When we were talking about J64 one suggestion for higher-way SMP was a
simple NUMA approach where each pair of processors have their own DRAM
controller with attached 256 megs of ram, and then a ring bus to pass
cache lines around. But that's way blue sky at this point, not a
concrete design yet.)
> But if those DSP's has I/O capability that wouldn't be needed.
DSPs generally do not have significant lateral I/O capability (one
input, one output, work on a small buffer). They don't have interrupts
>>> 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.
You can dedicate a processor to the realtime task, yes. That's how
Google does their self-driving cars, they don't even use rtlinux, they
just taskset each process to a specific processor and have one for the
system (which the kernel threads are all taskset to).
They did a video on this at ELC back in 2013:
If you're not comfortable enough with Linux to be sure it can keep its
hands off your process, you can have the process run on the bare metal
under an RTOS. That's about how Android works on Snapdragons, with the
Arm "scorpion" processor running Linux and the QDSP6 "hexagon" processor
running a hand-rolled ball of qualcomm realtime weirdness that handles
baseband signal processing and also offloads video/audio compression
stuff. In the snapdragon case they _could_ both be android chips (or
more likely could both be hexagon chips, which was part of the
motivation behind porting linux to run natively on hexagon in 2010, but
there was qualcomm internal politics between the Austin and Raleigh
campsus and the lawyers were the ones in control of the company anyway
so it didn't really matter what either engineering group wanted...).
>>> 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.
You can do that now in the SMP version?
> I was
> talking about reducing the number of parts, not adding to it. You are
> the one talking about adding things.
You're talking about adding an MCU.
> But a 2 channel DAC and ADC with signed data is not wrong.
That's why we have a DMA engine?
> Do you have anything specific against DSP applications and real-time?
No, but I seem to fairly consistently have no idea what you're talking
about. (And I'm mostly a software guy anyway.)
>>> 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 was me attempting to communicate that I have no idea what you're
talking about, that you seem to have made a random suggestion about
layout changes in the absence of an actual use case, and that you're
welcome to do so in your own chip because you have the source, good luck
>>> 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.
Yes, that's why the rtlinux project existed 20 years ago and why Thomas
Gleixner maintains an rtlinux fork and clearly Google's self-driving
cars are hallucinations that don't actually exist...
If you're arguing they're not _sufficient_ capabilities at 62.5 mhz,
that would be why Jeff's looking at rtmux. (I'm still not sure how it's
conceptually different from adeos a decade ago, but it does appear to be
much lighter weight. Either way, something intercepts interrupts, can
run arbitrary code in the interrupt handlers, and then hand off to Linux
(or not) afterwards.)
>>> 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
I mostly don't personally bother, no. (I did plenty of 8-bit programming
back in the day, but none of it was in C. I haven't done 16-bit C
programming since DOS. (I'm aware of http://elks.sf.net but didn't play
with it.) I've done bare metal programming in u-boot and such this
decade, but other than J-core most recently that was on hexagon, Armv7,
Cortex-M.) Back when I maintained my own fork of tinycc circa 2008 it
did have output for TMS320 but I didn't have a test environment for that
I assume your hardware vendor can point you to a relevant toolchain, if
not an outright BSP?
> 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.
If you decide you need an MCU, you'd need a way to program it, yes.
> 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.
When we first implemented SMP in J-core, before we added SMP support to
the j-core Linux target, we ran programs on the second processor in
their own reserved area of memory to test cacheline contention and the
spinlock implementation and such. You can still do that today if you
like. Doesn't require special hardware to dedicate a processor to
realtime stuff outside the control of Linux entirely, if you like.
>>> 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
I wouldn't try to run two instances of Linux on the same machine (modulo
virtualization), but you can run Linux and non-Linux on different
processors. That's fairly common.
> The context switching in linux would take more power and gain
> poor results, than using one extra core with a small amount of RAM.
I'm under the impression tying a third processor into the L1 cache
design we have now would be a routing nightmare, so adding a third
processor at the moment means it wouldn't share memory but would instead
have its own sram. It got proposed as a way to handle a couple things,
but didn't happen because it's not worth the transistors.
There's higher-way SMP stuff on the horizon, but it's J64 territory. Not
for quite a while yet.
>>> 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.
You are welcome to make your own ASIC. We talked about how a kickstarter
could do it in our ELC talk.
Part of the reason _we_ are doing an asic is to make sure our test
vectors (the giant pile of highly granular hardware test cases that make
sure the different backend doing its own synthesis and elaboration and
such produced the right behavior before you spend money making a mask)
actually provide full coverage.
> And that it would
> be an idea to have a MCU built into that ASIC it to do real-time
You are welcome to put anything you like into your ASIC. That was the
point of the "and blinky lights" comments above. Have fun. We'll be over
>>> 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.
Usually people who have linux and something else running on different
processors load the something else from linux using a kernel module (the
processors start quiesced), or if it's on a different kind of processor
they sometimes use the Linux "firmware loading" mechanism. But feel free
to reinvent this wheel in a different way I guess?
>>> 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?
Yes, I agree I haven't understood most of what you've said.
I'm going to stop replying at this point. Clearly you have your own
ideas of what you want to do, which have not been altered in any way by
interaction with me.
Good luck with your thing, you have the code. Let me know if you have
specific technical questions about any of the existing stuff.
More information about the J-core