LowRISC To Feature Tagged Memory & Minion Cores

[phoronix]

Phoronix: LowRISC To Feature Tagged Memory & Minion Cores

Earlier this year we wrote about lowRISC as an open-source SoC design using the RISC-V ISA. LowRISC hopes to ultimately get into volume silicon production and now they've released some documentation describing two planned features...

http://www.phoronix.com/vr.php?view=MTg2OTQ

[plonoma]

More details about the minion cores would be most welcome.
I find the article somewhat empty. Needs more information.

How complex are they? Clock speeds? How many? Power requirements?
Architecture and capabilities?

[plonoma]

After reading http://www.lowrisc.org/downloads/low...o-2014-001.pdf

Wouldn't implementing high speed interfaces such as USB and Ethernet (Gigabit) high speed, high throughput data transfer unit (DMA instead of shim) one for each minion, for the minions? Wouldn't each minion have to be able to work at high speed thus undoing the power savings? Especially if you want to use minions concurrently, in parallel?

[plonoma]

In my previous post. I meant wouldn't implementing high speed interfaces such as USB and Ethernet (Gigabit) need a high speed, high throughput data transfer unit (somewhat more of a DMA block instead of a shim) one for each minion, for the minions?

[asbradbury]

Yes, high speed protocols would need a PHY/transceiver and you'd need more than basic shift register support. The first step is getting the minion cores working well for relatively low-speed protocols. Ethernet/USB etc comes after that.

The minion cores are RISC-V just like the main application core. We may decide to pay a little more in area to make them 64-bit to give more opportunity for sharing code between them and the main cores. They would implement the integer subset of RISC-V (i.e. no native floating point), possibly with some extra bit manipulation instructions useful for I/O. The supported clock rate should be at least 500MHz, very possibly up to the same rate as the main applications cores (i.e. >=1GHz). You'd also want the ability to clock them much lower (in the 10s of MHz, or even at the khz level for very low power operation).

[plonoma]

When writing parallel algorithms, will it be possible to use the integer unit of the minion cores together with the main cores to have very powerful, parallel processor? It sounds like the minion cores would be able to do that with the shared memory space, 64bit pointers, etc...

Will you be making a complete SoC, including a BIOS based on Coreboot?

[asbradbury]

When writing parallel algorithms, will it be possible to use the integer unit of the minion cores together with the main cores to have very powerful, parallel processor? It sounds like the minion cores would be able to do that with the shared memory space, 64bit pointers, etc...

Will you be making a complete SoC, including a BIOS based on Coreboot?

Yes, there is potential for using the minion cores for general purpose computation. How feasible that is depends on the details of the eventual solution we end up with for communication and synchronisations between minion cores and between the application cores and minions.

We are aiming for a complete SoC. Coreboot seems an obvious choice, and I had a very productive chat with one of the coreboot devs recently. Key feedback there is that the ability to use L2 cache as memory in early boot is very useful. Using a minion core for early boot and using the shared scratchpad may be sufficient.

[coder]

The big problem in harnessing these minions for general-purpose computation will be scheduling. If they're implementing wire protocols, then they'll be under hard realtime timing constraints, so probably dedicated to just one or a couple things.

As I see it, the simpler the minions can be kept, the more die area would be available for general-purpose cores.

[coder]

BTW, it might be neat to have an opensource microcontroller based on one of these minion cores.

[plonoma]

The big problem in harnessing these minions for general-purpose computation will be scheduling. If they're implementing wire protocols, then they'll be under hard real-time timing constraints, so probably dedicated to just one or a couple things.

If you can make it work performant for easy to parallel and embarrassingly parallel problems then it's good enough.
With those minion cores you will need a lot of bus bandwidth. All those cores (both general purpose and minion) will need a lot of low latency memory data transfer capability, throughput if computing parallel problems together concurrently.

BTW, it might be neat to have an opensource microcontroller based on one of these minion cores.

You would need a general purpose core for that.
A simplified, downclocked microcontroller with a single general purpose core and a few minions would be very interesting.