[libre-riscv-dev] Advanced Topics on RISCV

[libre-riscv-dev] Advanced Topics on RISCV

[Immanuel, Yehowshua U]

I’ve read through the Spike page and a good portion of the simpleV page.

My two goals at the moment are:
1. Understand how RISCV handles multiple processes and does page walking
2. Understand how multicore ROSCV would work

I’m hoping to play with FreeRTOS soon so I can run through its codebase for setting up page tables.
Also, do you know if spike tests the special instructions like exception instructions? Also, what RISCV instructions would a kernel use to set up the pagetables?

Lastly, do you know any good resources for intro to multicore systems? RISCV doesn’t seem to have any multicore specific instructions. My current questions would include things like:

1. How can the kernel assign tasks to a certain core? If you have a process with multiple threads, it would make sense to spread out the threads among available processors instead of concentrating them on a single core. How might this work with respect to RISCV?

2. Does the hardware ensure cache coherency - that is - externally - software sees one big cache all though I imagine each core would have a local cache that would have to communicate with other caches?

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Advanced Topics on RISCV

[Luke Kenneth Casson Leighton]

On Tue, Mar 24, 2020 at 11:52 AM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> I’ve read through the Spike page and a good portion of the simpleV page.

it's ultimately quite simple in concept: the details are where it gets hairy

> My two goals at the moment are:
> 1. Understand how RISCV handles multiple processes and does page walking

ok so SV will not help you there: it doesn't have anything to do with PTW (etc.)

multiple processes are handled by context-swapping.  register and CSR
state are "saved", the new process selected, and its state "swapped
in" to registers and CSRs.  the last thing that's swapped over is: the
Program Counter.

PTW - you'll need to do quite a bit of research into virtual memory,
TLBs, etc. first.

> 2. Understand how multicore RISCV would work

you'll need to look up "Weak Memory Model" (as opposed to "Total Store
Order").  then look up AMO (atomic memory operations).

> I’m hoping to play with FreeRTOS soon so I can run through its codebase for setting up page tables.

that's a good idea.

> Also, do you know if spike tests the special instructions like exception instructions? Also, what RISCV instructions would a kernel use to set up the pagetables?
>
> Lastly, do you know any good resources for intro to multicore systems? RISCV doesn’t seem to have any multicore specific instructions.

correct.  it has LR/SC semantics on atomic operations, and it is
entirely up to the *operating system* - the kernel - to use these in
an effective way in order to guarantee that memory corruption between
processes does not occur.

*that is all there is to it*.

> My current questions would include things like:
>
> 1. How can the kernel assign tasks to a certain core? If you have a process with multiple threads, it would make sense to spread out the threads among available processors instead of concentrating them on a single core. How might this work with respect to RISCV?

just like it would on any multi-core operating system which was
running on an SMP-capable hardware.  there's absolutely no difference
here.


> 2. Does the hardware ensure cache coherency -

nnnope.  that's what a "Weak Memory Model" is.

> that is - externally - software sees one big cache all though I imagine each core would have a local cache that would have to communicate with other caches?

nnope.

that's why LR/SC atomic semantics exist.  look up AMO.  these are then
used to do kernel-level spin-locks, mutexes etc. all of which are a
hard requirement for sorting out memory clashes.

from my (brief) look at several RISC-V SMP implementations, the
takeaway that i got was: most implementations actually put the AMO ALU
*actually in the L2 cache* (!) - one *single* AMO ALU - accessible
*ONLY* over an exclusive bus such that ONLY one core may use it at any
given time.

thus, atomicity of the Atomic Memory Operations - crucial to - are
done by way of resource contention / starvation, rather than "actual
atomic but parallel memory operation detection and clash avoidance".

given that AMOs are not very common, they basically get away with this
approach.  however for massively-parallel SMP systems (64 cores or
greater) this approach would begin to result in significant contention
and slow-down of certain tasks.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Advanced Topics on RISCV

[Immanuel, Yehowshua U]

> given that AMOs are not very common, they basically get away with this
> approach.  however for massively-parallel SMP systems (64 cores or
> greater) this approach would begin to result in significant contention
> and slow-down of certain tasks.

So how would you get around this for >64 core RISCV CPU?

Yehowshua

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Advanced Topics on RISCV

[Jean-Paul Chaput]

[-- Attachment #1.1: Type: text/plain, Size: 2604 bytes --]



Hello Immanuel,

About manycores, we did a lot of work on that topic in our lab
(Sorbonne Université/LIP6). I send you a reference toward the
project we developed. This is a huge lot of work and may take
a lot of time to understand. But, we made a real chip with
16 cores to prove it works (and it do work). I cannot give you
more technical information as it not my field of expertise.

You must distinguish two case:

* Multi cores ( < 16) in that case, simpler solutions can be
  used.

* Many cores ( > 16) in this case, the TSAR project can be
  of interest.

TSAR (Tera-Scale ARchitecture).

You can see details here:
    https://www-soc.lip6.fr/trac/tsar

Best regards,


PS: Already signaled it to Luke.


On Tue, 2020-03-24 at 11:51 +0000, Immanuel, Yehowshua U wrote:
> I’ve read through the Spike page and a good portion of the simpleV page.
> 
> My two goals at the moment are:
> 1. Understand how RISCV handles multiple processes and does page walking
> 2. Understand how multicore ROSCV would work
> 
> I’m hoping to play with FreeRTOS soon so I can run through its codebase for setting up
> page tables.
> Also, do you know if spike tests the special instructions like exception instructions?
> Also, what RISCV instructions would a kernel use to set up the pagetables?
> 
> Lastly, do you know any good resources for intro to multicore systems? RISCV doesn’t
> seem to have any multicore specific instructions. My current questions would include
> things like:
> 
> 1. How can the kernel assign tasks to a certain core? If you have a process with
> multiple threads, it would make sense to spread out the threads among available
> processors instead of concentrating them on a single core. How might this work with
> respect to RISCV?
> 
> 2. Does the hardware ensure cache coherency - that is - externally - software sees one
> big cache all though I imagine each core would have a local cache that would have to
> communicate with other caches?
> 
> Yehowshua
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
-- 

      .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
      /v\     Jean-Paul.Chaput@lip6.fr
    /(___)\   work: (33) 01.44.27.53.99              
     ^^ ^^    cell:      06.66.25.35.55   home: 09.65.29.83.38

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    S o C     System On Chip

[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Advanced Topics on RISCV

[Immanuel, Yehowshua U]

> You can see details here:
> https://www-soc.lip6.fr/trac/tsar

Thanks, I see that it scales up to 1024 - that's fantastic.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Advanced Topics on RISCV

[Jean-Paul Chaput]

[-- Attachment #1.1: Type: text/plain, Size: 991 bytes --]

On Tue, 2020-03-24 at 13:00 +0000, Immanuel, Yehowshua U wrote:
> > You can see details here:
> > https://www-soc.lip6.fr/trac/tsar
> 
> Thanks, I see that it scales up to 1024 - that's fantastic.

  Yes. Even above that. We did use free tools for the HDL,
  but unusual ones. So maybe you should concentrate on the
  theoretical mechanisms and avoid banging your head on the
  tools themselves. The prototype, If I remember correctly
  is made in 28nm with on MIPS32 processors.
    The chip was implemented with Cadence however. But the
  HDL models are free.
    We have run NetBSD and Linux on it.

-- 

      .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
      /v\     Jean-Paul.Chaput@lip6.fr
    /(___)\   work: (33) 01.44.27.53.99              
     ^^ ^^    cell:      06.66.25.35.55   home: 09.65.29.83.38

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    S o C     System On Chip

[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev