In the past we’ve covered SoCs comprised of Arm cores and FPGA fabric via Xilinx Zynq-7000 series SoCs and Zynq UltraScale+ series MPSoCs, respectively featuring up to two Arm Cortex A9 cores, and up to four Cortex A53 cores.
MicroSemi has now announced an alternative, not based on Arm cores, but instead based on SiFive U54-MC RISC-V cores combined with PolarFire FPGA fabric.
PolarFire FPGA RISC-V SoC key features & specifications:
- FPGA – Microsemi PolarFire FPGA
- Processor Cores – Up to 4x SiFive U54-MC RISC-V cores clocked at up to 1.5GHz (performance similar to Cortex-A35 cores); 28nm process
- Deterministic Coherent Multi-core CPU Cluster
- Deterministic L2 Memory Subsystem
- System Memory I/F – Integrated DDR4/LPDDR4 Controller and PHY
- Storage – Secure Boot, 128K Boot Flash
- Debug capability
- Rich I/Os
- Low Power – Low static power; power optimized transceivers, up to 50% lower power compared to SRAM based FPGAs
So we don’t have the full picture just yet, and we’ll have to wait a little longer for more technical details, and the part numbers to be launched.
What’s not new is the development platform for MicroSemi PolarFire SoCs, and it combines RISC-V based HiFive Unleashed Linux development board together with the FPGA Expansion Board introduced last May. That probably means silicon is not available yet, and there’s no affordable cost PolarFire SoC devkit, as you’d have to fork about $3,000 to get started, contrary to Xilinx Zynq development boards which can be found for about $70 and up. But that’s the cost of being an early adopter…
PolarFire SoC support real-time determinism in a Linux environment, and are suitable for safety critical, system control and security applications combining Linux flexibility with real-time capabilities. While interviewed by LinuxGizmos, MicroSemi explained they were initially disappointed with the real-time performance, but the trick was to turn off the branch predictors for the E51 management core (yes, there’s a fifth core):
You can turn the branch predictor off in the E51 core, which boots the system and gets it up and running. This makes the core itself more deterministic, with all the cores coherent to subsystem. We can peel off a portion of L2 cache to provide direct access to memory, and peel off a bit more for a scratchpad coherent buffer for all the cores and that can be used for message passing between Linux.
SiFive is a very flexible IP provider, I find it hard to believe that Arm would do something like turn off branch predictors
I’d expect more details, and the actual launch of PolarFire FPGA RISC-V SoC to take place sometimes in 2019. You may want to monitor the product page as it gets updated over time.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
> SiFive is a very flexible IP provider, I find it hard to believe that Arm would do something like turn off branch predictors
I’m not into hard real time, but to the best of my knowledge, cortex-R series has been able to turn on and off branch predictors. A quick googling returns this:
According to this article, the branch predictor of Cortex-R family can be turned off using a register bit. I wonder if discarding branch predictor using SiFive IP actually saves space on the die.
I think the statement here means more about the IP block. It almost sounds like SiFive provide a “create your own core” wizard like Xilinx etc do for their IP cores. For ARM that level of customisation is probably only allowable in the tier that Apple etc are in to produce their own cores.
@dgp : Bingo! This is pretty much it. Now, if you aren’t against rolling up your sleeve, you can do that level of roll-your-own customization with VexRiscv. (https://github.com/SpinalHDL/VexRiscv)
As an aside, it’s only an RV32IM core, but the community is looking at what we can do to expand to RV64IM and maybe even go to a RV32G/RV64G. It’s FPGA friendly, but there’s quite literally nothing keeping you from taping out an ASIC with it.
Well, as one’d need to have an arm architecture license to modify an existing design, and that’s expensive, an open arch wins by default there.
It should be noted that this simply ties hard-macro/external SoC core to a PolarFire fabric. It means a bit of space on the FPGA going away to support the hard-macro if it’s one and the CPU will run at higher clocks (about double-to-quadruple the FMax of the FPGA implemented CPU/SoC) with a power consumption cost there. If you don’t need 64-bits, FP, quadcore, or 1.x GHz clocked CPUs, you can get 200-400 MHz individual RV32IM cores for about 3k cells in a modern FPGA of any kind (A trimmed down version of the VexRiscv CPU design was the winner of… Read more »