Multi Core NEORV32

[Luperior]

Hello everybody,
I am currently trying to develop a multicore NEORV32 processor to deploy on a XILINX PYNQ-Z2 as a thesis project.
My main issue is that I would like to perform a Triple Modular Redundancy control, and in order to do so I need to understand which is the signal that effectively carries the output data (let's say of a simple operation for example). Looking at the CPU instantiation, I was thinking about the "cpu_d.wdata" signal: could anybody confirm it? Do you have any warnings or suggestions?
Everything is highly appreciated, and thank you in advance for all your support.

[stnolting]

Hey @Luperior!

This really sounds like a cool project! 👍

Do you want to setup a multi-core cluster based on CPU level (neorv32_cpu.vhd) or on SoC level (neorv32_top.vhd, but with all peripheral/memories disabled)? I recommend the second approach as this still includes the on-chip debugger, which is very handy to debug bus interactions in such a system 😉

[...] I need to understand which is the signal that effectively carries the output data (let's say of a simple operation for example). Looking at the CPU instantiation, I was thinking about the "cpu_d.wdata" signal: could anybody confirm it?

Correct, that is the signal that carries the data being written to memory. Just for your information, the CPU's / SoC's bus interface is described in the documentation: https://stnolting.github.io/neorv32/#_bus_interface

[Luperior]

Dear @stnolting ,
I am really glad to see you interested in this project.
My idea currently takes place in the "neorv32_top.vhd" file, in line with what you suggest, where I instantiated three "neorv32_cpu.vhd" units (each with its own signals).
I am still struggling a bit to understand if and which of these can be shared, but I'll take a thorough look at what you linked and see if I can figure it out.
Thank you once more for your kind help and interest.

[stnolting]

How do you interconnect all these cores?

I made some experiments with a "full scale" bus crossbar in #631 (comment). Maybe that is helpful for you 😉

[Luperior]

I apologise for keeping you waiting, I took a few days off.
Unfortunately that is currently my main obstacle since other things have already been taken care of: I will now take a look at this example and see if that can help.
Thank you once more for your kind help, hopefully a nice result will be reached.

[stnolting]

I apologise for keeping you waiting, I took a few days off.

No worries 😉

Thank you once more for your kind help, hopefully a nice result will be reached.

GitHub user @NikLeberg made some experiments with a multi-core setup in https://github.com/NikLeberg/neorv32_soc. Maybe there are some things you could re-use.

Furthermore, we just added support for the RISC-V A extension in #651. This could be handy for synchronizing all the cores. We had a nice discussion about this and some multi-core-related issues in #573.

[Luperior]

GitHub user @NikLeberg made some experiments with a multi-core setup in https://github.com/NikLeberg/neorv32_soc

Thank you very much, this proved to be very helpful. I'll take a look at the other two discussions as well, now that the issue with the multicore design has been fixed. I was just wondering where the neorv32_busswitch behaviour was described in version 1.8.7, since I'd like to check with the TMR methodology the signal writing data into memory.

[stnolting]

I was just wondering where the neorv32_busswitch behaviour was described in version 1.8.7, since I'd like to check with the TMR methodology the signal writing data into memory.

What exactly do you mean?
There is no dedicated documentation in the data sheet for the bus switch as this an "infrastructure module" that operates transparently for the user. The module itself is now a part of neorv32_intercon.vhd.

neorv32/rtl/core/neorv32_intercon.vhd

Line 45 in 2e99380

entity neorv32_busswitch is

The bus switch is just a (prioritizing) multiplexer that switches two input ports A and B to one output port X. The switch can only alternate between requests - i.e. it stays in one position (A->X or B->X) until the current bus request is completed (via X.ACK or X.ERR). The corresponding bus protocol is described in the data sheet: DOC: Bus Interface

[Luperior]

You're right thank you, it took me a while to get to know this new version since I was using the April one until a few days ago.
Thank you again so much!