Performance Targets, PPA and Conclusion

The U8-Series microarchitecture will initially be productized as two IP offerings: The U84 and the U87 CPU cores:

The U87 will only be available later next year, whilst the U84 is also being finalised right now. The company has the U84 IP running internally on FPGA platforms.

The performance increases compared to previous generation SiFive cores are extremely impressive: Against a U54 at ISO-process, the new U84 features a 5.3x performance increase in SPECint2006. When taking into account the process node improvements that allow the U84 to clock higher, the generational increases that we’d be seeing in products will be more akin to a factor of 7.2x.

In terms of PPA, compared to a U7-series CPU, IPC increases come in at 2.3x resulting in 3.1x higher performance (ISO-process). A lot of the performance increases of the U8-series come thanks to the increased frequencies capabilities which are 1.4x higher this generation, with the core scaling up to 2.6GHz on 7nm.

On the same 7nm process, the U84 lands in at 0.28mm² per core and a cluster comprising four cores and a 2MB L2 cache measure in at 2.63mm². For comparison, a Arm Cortex-A55 as measured on the Kirin 980, also on 7nm, a core with its 128KB private L2 cache comes in at 0.36mm². Given that SiFive promises of similar performance to a Cortex-A72, which in turn would be more than double the performance of an A55, it looks like SiFive’s U84 core would be extremely competitive in terms of its PPA.

Finally, SiFive is able to configure of up to 9 CPU cores into a coherent cluster with a shared L2. The IP is also able to this in a heterogeneous way, similar to Arm’s big.LITTLE approach, employing both U8 and U7 series and even S-Series CPUs into the same cluster.

Conclusion - A Big Step In a Long Journey

Overall, SiFive’s new U8 core is I think a very important and major step for the company in terms of pushing its products and as well as pushing the RISC-V ecosystem forward. The key takeaway from the U8 is the massively improved performance of the core that now suddenly allows the company to seriously compete against some of Arm’s low- and mid-range cores.

I’m not really expecting to see the core employed in products such as smartphones any time soon as frankly SiFive still has a very long road ahead in terms of improving absolute performance. That being said, in the IoT and embedded markets, I think we’ll see faster and wider adoption of RISC-V cores, and SiFive is certain to see continued growth and interest for years to come. We’re looking forward in observing this future develop.

The U8-Series Microarchitecture
POST A COMMENT

69 Comments

View All Comments

  • vladpetric - Thursday, November 7, 2019 - link

    You're right. RISC-V SIMD, as opposed to classic SIMD, is really something to be excited about.

    I really disagree about auto-vectorising though, unless we're talking about FORTRAN code.

    The parent post implied that not having classic SIMD in RISC-V is something of a showstopper.
    Reply
  • ravyne - Wednesday, October 30, 2019 - link

    If their business was selling physical cores, you might have a point, but like ARM they're an IP company. But unlike ARM, adopters don't need an expensive architecture license to develop their own cores, and unlike ARM the architecture is designed for adopters to extend, with well-defined rules for operation encoding to do so. Early adopters are building their own cores, some with standard cores, but many with their own core designs or ISA extensions that would be impracticle in ARM's ecosystem. One of the reasons that companies don't really extend ARM is that you'd need a new ARM architecture license if ARM changes (as they did with ARMv8, say) and now you want to bring your investment forward -- you've locked yourself in to ARM licensing cost, and you're in a hard spot if you don't like the way ARM moves next.

    It's also worth noting that RISC-v has taken a lot of time to do their vector ISA right -- not only is the vector ISA homogenous and complete (every suitable scaler op has a vector equivalent) but it's structure is programmer-centric and forward-compatible -- that is, you write the vector code using the appropriate ALU width for the problem, and the CPU runs it across the full vector width it actually has. If you run your vector code on a machine 2 years from now and the vector unit is twice as wide, that same code runs twice as fast, and perhaps twice as fast again in two more years. Or 16 times faster next year on a specialized RISC-V vector accelerator. This is so much better than traditional SIMD ISAs like AVX/SSE/MMX, Altivec, or NEON -- if Intel had done this with their vector ISA, original SSE code would run 8-16 times faster today, instruction-for-instruction.

    You scoff at where they are 5 years in, but where they are is competitive with ARM's own current IP. The industry momentum shown by that and the ecosystem buildup around risc-v is incredible.
    Reply
  • Wilco1 - Wednesday, October 30, 2019 - link

    "where they are is competitive with ARM's own current IP"

    It might match performance of a 4.5 year old Cortex-A72 next year, maybe (*). But that's nowhere near being competitive with Arm's current IP... Arm sells much faster and more efficient cores like Cortex-A77.

    (*) It's easy to make bold claims in marketing, let's see how it performs in the real world.
    Reply
  • quadrivial - Wednesday, October 30, 2019 - link

    Most cellphones sold today are still using 4 or 8 A53 cores. A core that gets better performance in less die area is sure to attract some notice.

    More to the point, my raspberry pi 4 with 4x A72@1.5GHz along with a crappy SD card and 4GB of slow, single-Lane RAM is almost fast enough for daily use doing normal consumer things and light software development. 4 of these cores at almost twice the speed paired with slightly better IO and RAM is probably all the more computing most people need.
    Reply
  • Wilco1 - Thursday, October 31, 2019 - link

    It would be hard to find a niche that Arm hasn't already covered. Remember that both Cortex-A53 and A72 have fast dual floating point units as well as SIMD, but the U8 doesn't include SIMD, so any area comparisons are going to look great for the U8. Reply
  • name99 - Wednesday, October 30, 2019 - link

    Parts of the RISC-V community have been investigating an instruction set that looks like SVE
    https://content.riscv.org/wp-content/uploads/2018/...

    But that seems to have got entangled with a DIFFERENT research concept (namely run the vector engine asynchronously from the rest of the CPU), which certainly can't help with getting the ideas in commercial production on time.

    I've no idea how this will play out
    - full Hwacha (SVE + decoupled execution)
    - Hwacha as a "normal" sort of instruction set, like SVE, or
    - commercial partners settle on a smaller NEON-like instruction set to get basic SIMD up and running.
    Reply
  • Samus - Wednesday, October 30, 2019 - link

    This is obviously a application specific product and not meant to be as universal as ARM or off the shelf RISC SoC's.

    It seems their edge is in having efficient execution units to reduce power consumption so this will be good for ultra low power devices that still need decent performance.
    Reply
  • cpuaddicted - Wednesday, October 30, 2019 - link

    You mean not unlike the SVE capable ARM chips available today? lol Reply
  • Samus - Thursday, October 31, 2019 - link

    How is SVE even remotely comparable to this? An extension to ARM still has the inherent 'flaws' of ARM. That its RISC. Adding x64, SSE, SVX, VX, etc to x86 didn't change that fact its still x86.

    You clearly lack the foresight to see this company has a (niche) product that fills a gap in the market.
    Reply
  • bcronce - Wednesday, October 30, 2019 - link

    Ideal RISC does not support SIMD because one of the requirements of RISC is a single instruction does a single operation. SIMD "Single Instruction Multiple Data" is antithetical to that. Even the RISC-V designers view SIMD/VectorProcessing as a necessary evil and purposefully keep it limited. Reply

Log in

Don't have an account? Sign up now