C66x resource scheduling

[MDX]

I wonder how much sophisticated resource scheduling regarding C66x DSP cores can be. For example, i estimated that code of my project's software would need at least 2 cores' entire processing capacity (according to TI documentation) to be able to work in hard real-time. But then i have so much untapped processing power that can be used by third party plugins. Can i partition workload on DSP's like in generic-purpose CPU?

[John Syne]

If you use TI’s RTOS, then yes.

Regards,
John

> On Jun 25, 2017, at 7:33 AM, MDX <speed...@gmail.com> wrote:
>
> I wonder how much sophisticated resource scheduling regarding C66x DSP cores can be. For example, i estimated that code of my project's software would need at least 2 cores' entire processing capacity (according to TI documentation) to be able to work in hard real-time. But then i have so much untapped processing power that can be used by third party plugins. Can i partition workload on DSP's like in generic-purpose CPU?
>

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/8e94a34b-f4b4-422a-920a-20cc6fa7a5a5%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[MDX]

And if not? Can i partition DSP cores using Linux?

[John Syne]

You can operate them independently. You use Linux to load the DSP firmware for each core and then take them out of reset. The same goes for the CortexM4 and PRUs.

Regards,
John

> On Jun 25, 2017, at 7:02 PM, MDX <speed...@gmail.com> wrote:
>
> And if not? Can i partition DSP cores using Linux?
>

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b6397920-5775-499f-868a-d14690fa6202%40googlegroups.com.

[MDX]

By firmware you mean C program code?

[Dennis Lee Bieber]

On Mon, 26 Jun 2017 04:16:23 -0700 (PDT), MDX
<speed...@gmail.com> declaimed the
following:

>By firmware you mean C program code?

Only loosely... Since one doesn't have to use C to produce it...

The loadable, binary, image that is built for that processor. Depending
upon the task, it is just possible that the same source code might be
usable on each of the processors, as long as the build tools were commanded
to use the correct tool-chain (source -> C66x image vs source -> M4 image
vs source -> PRU image).

These are absolute images, there is no OS with them (unless, as
mentioned you build something like TI-RTOS into the image [or port FreeRTOS
to the processor]). Linux runs on the main application processor and is
used to load the images onto the ancillary processors, after which they run
independently.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Przemek Klosowski]

On Mon, Jun 26, 2017 at 7:16 AM, MDX <speed...@gmail.com> wrote:

By firmware you mean C program code?

I don't know what I can assume about the context of your question, so please forgive me if guess wrongly and explain things that are obvious to you or, conversely, talk over your head---please clarify in response.
You asked about coordination and partitioning of DSP coprocessors, which to me implies  a unified system that manages both the main CPU and the coprocessors on a similar plane. This is not how Linux sees the coprocessors: while the CPU cores are indeed managed as an ensemble by the kernel, the coprocessors are seen as peripheral resources. Linux kernel may help loading them with their binary firmware, and starting and stopping them, but you need to write all the synchronization primitives yourself.
The DSPs (and PRUs, etc) will be running their own code but will not have the usual set of Linux system calls (unless you somehow implement them yourself in your firmware). You can write the DSP/PRU code in their respective assembler, or in the C variant understood by the DSP/PRU C compiler, which is different than the C compiler used by the main CPU.

The newer kernels provide more functionality via the RemoteProc subsystem, but it's just a way of managing high-level stuff like firmware loading, starting/stopping, and communication with the coprocessors. You still can't manage the computational tasks homogenously, e.g. moving them forth and back between the CPU and coprocessors---instead, you need to split up processing tasks between the CPU and coprocessors, write the code, deploy and start the binaries, and communicate and synchronize their operation.

[MDX]

Well, you guessed (almost) correctly and your answer pretty much fills my list of requirement. Now i wonder if that "high-level communication" is enough to control resource sharing between C66x software processing samples in programmed order, so that it stays in real-time

[John Syne]

First you have to define what you mean by “real-time”. To most it means completing a task in a well defined amount of time. As long as you don’t turn off interrupts for extended periods, there is no reason why the responsiveness isn’t deterministic.

Coordinating between the DSPs is something you have to setup in your software. You can do this via shared memory, interrupts, etc.

BTW, the TI C-compiler used for the DSPs is extremely good and in many cases is more efficient than programming in assembly. Only the most highly skill DSP programmer will be able to achieve better assembly performance vs C-code.

Regards,
John

> On Jun 26, 2017, at 10:36 AM, MDX <speed...@gmail.com> wrote:
>
> Well, you guessed (almost) correctly and your answer pretty much fills my list of requirement. Now i wonder if that "high-level communication" is enough to control resource sharing between C66x software processing samples in programmed order, so that it stays in real-time
>

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e8744846-2529-4fde-b0d7-384bf2d979e3%40googlegroups.com.

[MDX]

Well, samples are part of stream that must "return" to output in-order and with a minimal latency, and i never planned to use asm

[John Syne]

So what is the maximum latency to can tolerate?

Remember, each DSP has 8 functional units (two multiply units and 6 ALUs) which means you can execute up to 8 instructions per cycle.

Here are some core benchmarks:

http://www.ti.com/lsds/ti/processors/technology/benchmarks/core-benchmarks.page

Regards,

John

On Jun 26, 2017, at 9:34 PM, MDX <speed...@gmail.com> wrote:

Well, samples are part of stream that must "return" to output in-order and with a minimal latency, and i never planned to use asm

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3f0604ab-35b5-4e32-a89d-74fff9ffeb79%40googlegroups.com.

[MDX]

Output must be a constant stream upon any input and 10ms is considered as a critical issue

[John Syne]

Well, that depends on how complex your algorithm is, but in most cases, 10ms latency should not be a problem.

Regards,
John

> On Jun 28, 2017, at 7:36 AM, MDX <speed...@gmail.com> wrote:
>
> Output must be a constant stream upon any input and 10ms is considered as a critical issue
>

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ffb698e6-8b37-4add-86aa-d091bc33d4c2%40googlegroups.com.