Cannot statically allocate task to multicore

[BottCode]

Hi,

I'm working with the CoraZ7-10 dual core version (Zynq-7000) and GNAT 2019.
I'd like to run a multitasking application whose tasks are statically allocated to the cores. For instance: Task_1 must run on first core, while Task_2 on the second one.

Following this presentation, I've tried what they suggest on slide 21.

Here is my code
Main

pragma Profile (Ravenscar);

with laborer;

procedure Main is
begin 
  loop
      null;
  end loop;
end Main;

Pkg laborer spec

with System.Multiprocessors; use System.Multiprocessors;

package laborer is

  task type Allocated_Task (Affinity : CPU) with CPU => Affinity;

  L1 : Allocated_Task (CPU'First);
  L2 : Allocated_Task (CPU'Last);

end laborer;

Pkg laborer body

package body laborer is

  task body Allocated_Task is
  begin
    loop
      null;
    end loop;
  end Allocated_Task;

end laborer;

This code does not compile because, on laborer spec, the compiler says "Affinity" is undefined.

So, I've tried this:
Main

pragma Profile (Ravenscar);

with worker;

with System.Multiprocessors;

with System.BB.Parameters;

procedure Main is
 Is_Multi : Boolean := System.BB.Parameters.Multiprocessor;
 No_CPU : System.Multiprocessors.CPU := System.Multiprocessors.Number_Of_CPUs;
begin 
  loop
    null;
  end loop;
end Main;

Pkg worker spec

with System.Multiprocessors; use System.Multiprocessors;

package worker is

  task type T1 with CPU => CPU'First;
  task type T2 with CPU => CPU'Last;

  WORK_1 : T1;
  WORK_2 : T2;

end worker;

Pkg worker body

package body worker is

  task body T1 is
  begin
    loop
      null;
    end loop;
  end T1;

  task body T2 is
  begin
    loop
      null;
    end loop;
  end T2;

end worker;

This code compiles, but it does not work.
Using XSDB, I can see that only the main procedure is scheduled on the first core, while the tasks defined in package worker (i.e. WORK_1 and WORK_2) are never scheduled on any core.

So, I've set two breakpoints just to see what is happening. The first is set on the null; instruction in the main procedure loop, while the second one is set on the end loop; instruction of the same loop.

Something quite strange happens, as you can see in the following images.

TheIs_Multi variable is set to 0, i.e. False. So, this means that the runtime environment is not aware of the second core. Isn't it? That would be a bad news.
However, the No_CPU variable is set to 2, so two cores are detected, right?

On the second breakpoint, as seen in the previous image, the No_CPU variable is set to 16!
This confuses me a lot.

This is my project file

project Try is

  for Languages use ("ada");
  for Main use ("main.adb");
  for Source_Dirs use ("src");
  for Object_Dir use "obj";
  for Runtime ("ada") use "ravenscar-sfp-zynq7000";
  for Target use "arm-eabi";

  package Compiler is
    for Switches ("ada") use ("-g", "-gnatwa", "-gnatQ");
  end Compiler;

  package Builder is
    for Switches ("ada") use ("-g", "-O0");
  end Builder;

end Try;

What am I doing wrong? Thanks in advance.

[lambourg]

By default the zynq7k runtime is monoprocessor, as seen in s-bbpara.ads: Max_Number_Of_CPUs : constant := 1;

You will need to change this value to 2 to be able to use the two cores.

Best regards,

• Jerome

[BottCode]

Hi @lambourg,

I've modified Max_Number_Of_CPUs and I've tried to re-build the runtime library.
Unfortunately, the compilation fails:

The error message is not so explanatory, maybe you can give me more details.

P.S. I've also tried, just to check, to re-build other runtime library. The same error appears re-compiling the Ravenscar_Full_Tms570Lc and Ravenscar_Full_Microbit, without changing anything in the source code.

[lambourg]

How are you rebuilding the runtime?

[BottCode]

Simply by opening arm-eabi/BSPs/ravenscar_full_zynq7000.gpr with GNAT Programming Studio 19.1 and using the action "Build all".
I've also tried in this way, but the outcome is the same.

[BottCode]

@lambourg, I'm an idiot. I was attempting to compile the runtime library of GNAT 2019 using the GNAT 2020 toolchain... I had not noticed that the GNAT 2020 installation interfered with that of GNAT 2019. Now the compilation ends successfully.

Now, with the new runtime, the tasks seems to be scheduled on the cores. Not sure if this happens for both cores and for the whole task set, but I'm checking.
Anyway, thanks for your support and kindness.

[lambourg]

Yes, the build system for the runtime has changed between the two releases, and are not compatible. We've just updated the README to take this change into account.

Best regards,

• Jerome