We first covered SiFive when they unveiled their open source Freedom RISC-V SoCs. Since then, they moved away from open source for their customizable IP, since their customers did not require fully open source designs, but kept releasing more RISC-V cores such as 32-bit E31 Coreplex & 64-bit E51 Coreplex, as well as offering their one-time fee pricing without recurring royalties, contrary to what some competitors – such as Arm – are doing.
The company has now just announced U54-MC Coreplex quad core real-time capable application processor with support for full featured operating systems such as Linux.
U54-MC Coreplex main specifications / features:
- Fully compliant with the RISC-V ISA specification
- 4x RV64GC U54 Application Cores
- 32KB L1 I-cache with ECC, 32KB L1 D-cache with ECC
- 8x Region Physical Memory Protection
- 48x Local Interrupts per core
- Sv39 Virtual Memory support with 38 Physical Address bits
- 1x RV64IMAC E51 Monitor Core
- 4KB L1 I-Cache with ECC
- 8KB DTIM with ECC
- 8x Region Physical Memory Protection
- 48x Local Interrupts
- Fully Coherent TileLink Bus
- Integrated 2MB L2 Cache with ECC
- Real-time capabilities – Both the L1 Instruction Cache and the L2 Cache can be configured into high speed deterministic SRAMs
- CLINT for multi-core timer and software interrupts
- PLIC with support for up to 511 interrupts with 7 priority levels
- Debug with instruction trace
- U54 Performance – 1.7 DMIPS/MHz; 2.75 CoreMark/MHz
U54-MC Coreplex has been taped out as part of Freedom Unleashed platform with all 5 cores, including U54 and E51, running at over 1.50 GHz and manufactured using 28nm technology. The company compares it to Arm Cortex A35 cores in the table below which shows the added features.
| U54-MC Coreplex | ARM Cortex-A35 |
|---|---|
| RV64GC M + S + U Mode |
ARMv8-A, AArch32, AArch64 |
| 16 bit instructions | AArch32 only |
| Physical Memory Protection (PMP) and MMU | None, MMU only |
| Real-time capable | Not applicable |
| E51 Monitor Core | Requires additional IP |
| Integrated interrupt controller | Requires additional IP |
More details about the U54-MC Coreplex can be found on the product page, and the company plans to release an U54-MC Coreplex development board in Q1 2018.
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.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
The major flaw of their first chip implementation is lack of USB support which will apparently require a secondary FPGA to add to the platform. Same goes for PCIe and other interfaces. Someone needs to make a better hardware implementation of this.
@TLS
They have interconnect IP too: https://www.sifive.com/products/peripheral-ip/
From there I’d assume you can add additional IP like USB, PCIe, GPIOs, etc… as needed
@TLS
I wouldn’t look at this as a flaw. Yes, IO part will flexible via FPGA, which allow to refine what is must-have-in-soc in the next stage (development boards). This can be developed in parallel. Time to market is also important. Without IO part SOC itself can be released faster, otherwise you would need to wait even longer before you get Linux-capable riscv64 board. These development boards are highly important as they will be used for the final bootstrap of ecosystem (we bootstrapped Fedora in late 2016, Debian, FreeBSD, etc have also ports). Think about early days of AArch64/ARM64. This will be the first time we run on native hardware instead of QEMU, Spike, RISCVEMU, etc. Think of this are FPGA -> SOC + FPGA -> .. -> SOC path.
Their processor comparison was clearly written by a marketing person with little review from engineers. Take the “16 bit instructions” like. It shows the Cortex-A35 as supporting “AArch32 only” which is odd as it supports AArch64, AArch32, and T32 (which has a mix of 32 bit and 16 bit instructions). Then there’s the like about the PMP. What’s the point of a PMP if you have a full up MMU? Or does it do something different than one would expect like memory encryption? If that’s the case, why is it even on that line as it’s a different animal entirely. The “Real time capable” line is similar. You can implement TCM with the Cortex-A35 quite readily. How about the interrupt controller line. Can you even license the A35 without the GIC?
I’d love to see power efficiency numbers for this chip. Given the clock speed they’re quoting on that 28nm process, I’m not looking forward to anything very good. Add in the inefficiency of having to use an FPGA for I/O and you can forget a lot of embedded applications for SoCs based on this core. I’m all for Open designs, but pick a fight in your weight class–go after MIPS.
U54 doing 1.5GHz at a 5-stage in-order pipeline is mighty impressive. U54’s DMIPS/clock is inline with ppc603e, which to this day remains one of the best CPUs I’ve worked with.
I think this part means that 16-bit instructions are only useful in 32-bit mode on ARM, which is true. You cannot reference 64-bit registers, 16-bit instructions are part of the T32 instruction set. But overall I tend to find their comparisons a bit confusing if not misleading.
@TLS
According to their site, the new platform should support “High Speed Peripherals: PCIe 3.0, USB3.0, GbE, DDR3/4”
https://www.sifive.com/products/freedom/
The platform datasheet also states:
“U500 SoCs can be configured with a range of high-
speed I/O devices, including Dual Mode PCIe Gen 3.0
with a configurable number of lanes and controllers,
USB 3.0 including OTG, and Gigabit Ethernet interfaces.
High-speed I/Os can master directly into the cache-
coherent memory system, and can optionally allocate
data directly into the shared L2 cache.”
https://static.dev.sifive.com/SiFive-Freedom-U500-datasheet-v1.0.pdf
@willmore
The target applications here is everything aarch32 gave up on when they bloated the L1 and L2 by dropping the 16bit addressing instructions and went with an 8stage branch-predictor that makes you pay 8-16cycles on average for mispredict + tbl miss so you can’t use it in (almost general purpose) real-time switching.
Though being fair to ARM, they segmented things the way they did since, at the time, they had t32, a market full of DSPs, and two major designers (nVidia and AMD) swearing by VLIWs over RISC for tight graphic loads so they believed no one wanted general purpose cores for those loads.
It reminds me of how Intel kept missing their market with the Atoms for almost 5 years before giving up on them. They just couldn’t accept the fact their fancy branching was causing too much latencies for general purpose bytecode. They kept upping the frequencies and throwing cycles at it… At the end they even had fans in their tablet designs 😀 By comparison, ARM’s mistake was marginal.