The new BeagleV is a little different. It’s a small single-board PC with a RISC-V processor and support for several different GNU/Linux distributions as well as freeRTOS.
With prices ranging from $120 to $150, the BeagleV is pricier than a Raspberry Pi computer, but it’s one of the most affordable and versatile options to feature a RISC-V processor. The makers of the BeagleV plan to begin shipping the first boards in April and you can sign up to apply for a chance to buy one of the first at the BeagleV website.
It’s a good sign that RISC-V hardware is getting more accessible – a truly open source ISA is something we need to compete with the proprietary mess that is ARM.
Nice wishes, except only the base ISA of RISC-V is open, like on ARM there are extensions and OEMs are free to add extensions of their own.
Already enjoying the upstream contributions from Western Digital and NVidia for their use of RISC-V ISA?
Expect RISC-V to turn into Android of open source ISAs, then lets see which mess it will turn into.
Well to a degree, yes: https://github.com/chipsalliance/Cores-SweRV
But the point of those private extensions is to put proprietary IP in the silicon, just like WD, et all do with ARM. But WD for example sponsors the RISC-V organization, and development. I don’t think they would do that if they were forced to operated under a GPL like license for CPUs.
From where I sit, most of the exciting work in RISC-V is coming from research projects which are open, and the RISC-V group in defining public extensions.
If ARM organised themselves like the OpenGL ARB was organised a lot of mess could be sorted out very quickly although this would depend on vendor cooperation and sane licensing. Ditto Risc-V I suppose.
Going off on a multiple processor tangent back in the day the BBC Micro could use second processors via the bus. It’s 6502 could be complemented with a Z80 or NS 32016. The BBC Master system could accomodate an 80186 and ARM. There were also other aftermarket second processor systems which allowed for an 8088 or 68000 cpu and others. Then there’s the DEC Rainbow which had both Zilog Z80 and Intel 8088 processors. It’s interesting according to wiki how the CPUs would handle various tasks when the other was being used, although both executing software at the same time was theoretical it was never tested. I never knew until I read wiki it could be upgraded to an 80286 via an aftermarket upgrade.
Multiple CPU architectures are inherently complex, as each CPU has its own type of bus and bus handling. So you’ll always need CPU-specific bus extensions to allow two CPUs to communicate.
Yeah. The BBC Micro had an expansion interface called the Tube which attached to things you plonked second processors in.
https://en.wikipedia.org/wiki/Tube_(BBC_Micro)
Like so many things in life it is more complicated than that. The bus handling of the Z80 and 6502 are very similar, which is why the CP/M card for the Apple ][ was so simple, there was even a 68008 card for the Apple. Because it was all an 8 bit bus the small differences in bus handling didn’t need much circuitry at all.
However if you are talking on die non heterogeneous multiple CPU architectures, then everything is sharing the same bus architecture, crossbar, etc. Take a look at juxtapiton which uses the OpenPiton framework to mix OpenSPARC and RISC-V tiles: https://abopen.com/news/juxtapiton-merges-opensparc-risc-v-soft-cores. There is no reason one couldn’t add more architectures to OpenPiton
This is an interesting article on how ARM is allowing for an extension mechanism for custom op-codes and silicon, as well as the Risc-V bods. In very OpenGL ARB like but a bit more tied to hardware than software but the concept is pretty much the same. There’s conformancy tests, a base level which is the main instruction set of the cpu must be present, and a system to register custom op-codes, and ways of allowing both general and propriatory solutions to run code.
https://www.theregister.com/2019/10/08/arm_custom_instructions/
Sounds to me like ARM customers/RISC-V members (many are both) get what they want no mater what happens.
I’ve often thought what is the best way to frame RISC-V and I’ve come to the conclusion RISC-V is like an open standard just like HTTP or HTML. You can have open source and closed source implementations (lower levels like IPv4 and IPv6 or TCP also have hardware implementations). And widely available open source implementations exist. Hopefully like with many of those open standards their will be a lot of open source implementations for RISC-V as well.
Oh my word. This is interesting!
PCI Express arrives on the Raspberry Pi CM4 – A Guide
https://www.youtube.com/watch?v=x0wl3ZaOq_g