👆If you wish to meet often, feel free to star 🌟 and bookmark it~
Source: Content compiled from chipsandcheese, thank you.
RISC-V is a relatively young open-source instruction set. So far, it has gained attention in microcontrollers and academic applications. For instance, Nvidia has replaced the Falcon microcontroller in its GPUs with RISC-V based microcontrollers. Many university projects have also utilized RISC-V, such as Berkeley’s BOOM.
However, transitioning RISC-V to applications that are more visible to consumers and offer higher performance will be a daunting task. SiFive plays a key role in driving RISC-V CPUs to achieve higher performance goals, similar to that of Arm (the company). Both Arm and SiFive design and license IP blocks, leaving the task of creating complete chips to implementers.
By designing CPU modules, both SiFive and Arm can lower the entry cost for building higher-performance designs within their respective ISA ecosystems. However, to achieve this in the RISC-V ecosystem, SiFive needs to develop robust CPU cores. Here, I will introduce SiFive’s P550. This core aims to achieve a 30% performance improvement in less than half the area of its Arm Cortex A75 counterparts.
Like Arm’s cores, the performance of the P550 largely depends on how it is implemented. In this article, I tested the P550 implemented in the Eswin EC7700X SoC. This SoC features a 1.4 GHz quad-core P550 cluster with 4 MB shared cache. The EIC7700X is manufactured using TSMC’s 12nm FFC process. The SiFive Premier P550 development board housing the SoC has 16 GB of LPDDR5-6400 memory. For easier understanding, I have gathered some comparative data from the Qualcomm Snapdragon 670 found in the Pixel 3a. The Snapdragon 670 features a dual-core Arm Cortex A75 cluster running at 2 GHz.
Overview
The P550 is a 3-wide out-of-order core with a 13-stage pipeline. Out-of-order execution allows the core to bypass stalled instructions to extract instruction-level parallelism. This is crucial for achieving high performance, as cache and memory latency can be significant limiting factors in modern CPUs. The P550 is far from SiFive’s first out-of-order design. This distinction belongs to SiFive’s U87, which is also a 3-wide out-of-order design. The P550 arrives years later and should be more mature.
Like Arm’s Cortex A75, the P550’s performance depends on the implementation. Anandtech reports that the A75 has an 11-13 stage pipeline, but their charts indicate that the minimum misprediction penalty may be close to 11 cycles.
Both SiFive’s P550 and Arm Cortex A75 have moderately sized out-of-order execution engines. Both are far from the high-performance designs of today’s Intel and AMD, optimized for low power and area.
Branch Prediction
Fast and accurate branch prediction is crucial for both performance and energy efficiency. SiFive provides the P550 with a 9.1 KiB branch history table, which helps the core correlate past branch behavior with branch outcomes. From abstract testing, in increasingly longer random patterns with various numbers of branches taken/not taken, the P550’s branch predictor seems to have quite good pattern recognition capabilities. It falls short of high-performance core levels, but that is expected.
Compared to Arm’s Cortex A75, the P550 can handle longer patterns of a few branches. However, as more branches are added, the gap narrows.
The speed of the branch predictor is also important, especially in high IPC code with many branches. The P550 appears to have a 32-entry BTB capable of handling branches without bubbles. Moreover, as long as the tests fit within 32 KB, the core can process a branch every three cycles. It is likely that the P550 does not have another level of BTB. If a branch misses the 32-entry BTB, the core simply computes the target address of the branch before it reaches the front end. If so, the P550’s 32 KB L1 instruction cache has a 3-cycle latency.
Arm’s Cortex A75 also seems to use a single small BTB level. Both cores lack the large decoupled BTBs that high-performance cores usually possess.
The P550 uses a return stack of 16 entries to predict function call returns. The A75 seems to have a return stack of 42 entries, as the delay per call+return pair does not reach a tipping point before I exceed that value. Even with a larger return stack, A75’s higher 2 GHz clock speed allows it to achieve similar performance in common cases of return stack hits.
When exceeding the return stack capacity, the P550’s latency rises sharply. This contrasts with the A75’s more gradual latency increase. Perhaps the A75 only mispredicts the return address that gets pushed out of the stack. The P550 may not handle return stack overflow gracefully; even testing just a few entries beyond the return stack capacity, it mispredicts many returns.
Fetch and Decode
The P550’s front end features a 32 KB 4-way set associative instruction cache with parity protection, capable of providing sufficient bandwidth (12 bytes/cycle) to feed data to the downstream 3-wide decoders. As long as the code fits in L1i, the front end can maintain 3 IPC. The instruction bandwidth gradually decreases once it exceeds that value. Starting from L2, the core can still maintain a reasonable 2 IPC. The instruction bandwidth at L3 is suitable for 1 IPC, although you really hope that any L2 cache miss on any core is low.
Arm chose to provide a larger 64 KB instruction cache for the A75, giving it a better chance to satisfy instruction fetches from L1i. Instruction bandwidth drops sharply when there is an L1i miss. This largely depends on implementation decisions. Qualcomm provides 1 MB of system-level cache for the Snapdragon 670. System-level caches are typically closer to the memory controller than compute blocks. Therefore, they are usually not optimized for high performance for any one block. In contrast, the 4 MB L3 on the EIC7700X is closely related to the CPU cluster.
The fetched instructions are decoded into micro-operations, renamed, and reach the out-of-order back end.
Out-Of-Order Execution
SiFive’s P550 has slightly higher reordering capabilities than Arm’s Cortex A75. However, due to the out-of-order exit techniques inherited from the A73, Arm can push its out-of-order execution buffers further. On the A75, I used incomplete branches and incomplete loads to block exits.
Both cores have sufficient register file capacity compared to ROB size, although other structures, such as memory ordering queues, may be somewhat weak. The reordering capabilities of the P550 and A75 fall far short of current Intel and AMD cores, and even newer Arm cores like the Cortex A710. They are closer to Intel’s Core 2 or Goldmont Plus. However, a moderate out-of-order execution window is far better than in-order execution.
Both cores’ execution resource allocation considers low power and low area targets. Between the two, the P550 has a more flexible integer port setup and more scheduling capability to feed data to these ports. However, the Cortex A75 closely follows with two ALU ports and a separate branch port. Scalar integer workloads often have many branches, and the branch port does not require a write-back path to the register file. Arm’s setup may be cheaper while providing nearly the same performance.
In terms of floating-point, both cores have two FP ports capable of handling the most common operations. The P550 handles FP addition, multiplication, and fused multiply-add (FMA) with a latency of 4 cycles, indicating that the core uses the FMA unit to handle all these operations. After all, addition is just an FMA with a multiplier of 1, while multiplication is an FMA with an addend of 0. The A75’s FP addition and multiplication latency is 3 cycles, while FMA execution takes 5 cycles. Arm may use separate execution units for FMA and addition/multiplication. Alternatively, Arm may have an FMA unit whose path is optimized to execute either multiplication or addition only. The Cortex A75’s FPU also supports vector execution, giving it an advantage over the P550.
Microbenchmarking shows that the A75 has 31 scheduler entries available for floating-point operations. Anandtech states that the A75 has two 8-entry floating-point schedulers, but my measurements differ from that. The P550 has a total of 28 scheduler entries for floating-point operations. This may be a dual-port unified scheduler or two 14-entry schedulers. I have not found operations that only enter one port.
Memory Subsystem
The P550 is a small, low-power design that does not require the high-throughput memory subsystems seen in Intel, AMD, or Arm’s big cores. Memory operations are first generated by two address generation units (AGU). One handles loads, while the other handles stores. Both seem to be supported by relatively large schedulers, allowing the core to handle unbalanced workloads of loads and stores. The Cortex A75 also has two AGUs, but each AGU pipeline in the A75 can handle loads and stores. Having two load/store ports makes sense, as loads typically far exceed stores, so the P550’s load AGU may be very busy, while the store AGU is idle most of the time.
“We observed that the usage of two load/store ports is about 20%. We speculate that changing to a dedicated load port and a dedicated store port would not have a significant impact on performance… The facts prove that this change indeed results in a performance loss of less than 1%.” — David B. Papworth, “Tuning the Pentium Pro Microarchitecture”.
Interestingly, Intel evaluated the same trade-offs when designing the Pentium Pro in 1996. They found that using a less flexible load/store setup only had a slight impact on performance. SiFive may have reached the same conclusion. However, the P550 does have more reordering capability than the Pentium Pro, allowing it to better inform its execution pipeline (including AGUs) when cache misses occur.
The AGU generates program-visible virtual addresses that must be translated into physical addresses. The P550 uses a two-level TLB setup to speed up address translation. The first-level TLB is fully associative, meaning any entry can cache the translation for any address. However, both the data and instruction TLBs are relatively small, with only 32 entries. The larger 512-entry L2 TLB can handle simultaneous instruction and data L1 TLB misses. In the data side, fetching a translation from the L2 TLB incurs a 9-cycle penalty. Arm’s A75 has a larger TLB and incurs a lower 5-6 cycle penalty for hitting the L2 TLB.
Before accessing the cache, loads must check the store address based on older stores (and vice versa) to ensure correct ordering. If there are dependencies, the P550 can only perform fast store forwarding when the load and store addresses match exactly and both accesses are naturally aligned. Any unaligned access (regardless of dependencies) can confuse the P550 for hundreds of cycles. Worse, unaligned loads and stores do not proceed in parallel. An unaligned load takes 1062 cycles, while an unaligned store takes 741 cycles, totaling over 1800 cycles.
This poor behavior of unaligned accesses is atypical even for low-power cores. Arm’s Cortex A75 requires only 15 cycles in the worst case for two unaligned dependent accesses.
Diving into performance counters reveals that executing each unaligned load instruction results in approximately 505 executed instructions. The P550 almost certainly does not support unaligned access in hardware. Instead, it may trigger faults and let the operating system handlers simulate it in software.
Core Private Caches
The P550 has a moderate out-of-order execution engine without vector capabilities, so it does not require a large bandwidth from its memory subsystem. However, latency is crucial because the P550 lacks the extensive reordering capabilities seen in high-performance cores to tolerate memory latency. Like many AMD, Intel, and Arm designs, each P550 core has its own L1 and L2 caches, while the L3 is shared. All levels of the data cache hierarchy are ECC protected.
The P550’s 32 KB L1 data cache is 4-way set associative, capable of handling one load and one store per cycle (assuming no alignment issues). Thus, the maximum bandwidth is 16 bytes per cycle, achieved through a balanced read/write combination. The latency is 3 cycles, matching many low-clocked cores.
The L2 cache is 256 KB and 8-way set associative. It consists of two groups, with a latency of 13 cycles. This size and latency combination is somewhat outdated, as both Arm and AMD have implemented larger L2 caches with lower latencies. However, the P550’s L2 still captures L1 misses well and protects the core from L3 latency impacts. The L2 bandwidth is 8 bytes per cycle, which is moderate, and this limitation applies to both reads and writes. While this isn’t an impressive figure, considering the core’s lack of vector capabilities and single-load AGU, 8 bytes per cycle should suffice.
Arm’s Cortex A75 enjoys higher cache bandwidth due to its higher clock speed and more per-level bandwidth per cycle.
L3 Cache and Interconnect
The interconnect for the P550 must be modular and scalable to meet various market demands. Consumer-grade routers or set-top boxes may only require 2-4 cores, while small edge servers may need more cores. The P550 can instantiate as a cluster of up to 4 cores. It is presumed that the cores within a cluster share an external interface. Multiple clusters are placed on a “coherent system architecture” that directs traffic from P550 clusters to the appropriate destination. From the EIC7700X datasheet, this “coherent system architecture” is likely a cross switch.
Cacheable memory accesses point to the L3 cache, which can be shared among multiple P550 clusters and can store to meet the bandwidth demands of multiple cores. SiFive offers L3 capacity options of 1 MB, 2 MB, 4 MB, and 8 MB. The largest 8 MB option has eight banks reserved for multi-cluster configurations. The EIC7700X we are studying has a 4 MB L3 with four banks. Thus, the number of banks matches the number of cores.
Microbenchmarking indicates that the L3 can provide 8 bytes of bandwidth per core per cycle. Overall, the four-core P550 cluster on the EIC7700X has about 43.88 GB/s of L3 bandwidth. The L3 latency is about 38 cycles, which is quite good, considering the flexibility of the cache, this number is still decent. In contrast, Arm’s Cortex A73 uses a simpler two-level cache setup. The A73’s L2 serves as the first stop for L1D misses and a large last-level cache. This means compromise, so the 1 MB L2 capacity is smaller than the EIC7700X’s L3, but with better latency at 25 cycles.
L3 misses point to memory ports. Depending on implementation goals, the P550 multi-cluster complex can have one or two memory ports, each with a width of either 128 bits or 256 bits. Each memory port can track up to 128 outstanding requests for memory-level parallelism. Uncommon requests to IO or non-cacheable addresses will be routed to one of two 64-bit system ports or a 64-bit peripheral port. Implementers can also use one or two front-end ports, allowing other agents to perform coherent memory accesses through the multi-cluster complex.
Eswin chose to use a single memory port (possibly 128 bits wide) and two system ports. The first system port’s address space includes 256 MB PCIe BAR space, PCIe configuration space, and 4 MB ROM. The second system port accesses DSP’s SRAM, etc.
These ports connect to an on-chip network using the AXI protocol. At this point, everything is dependent on the implementer and is not under SiFive’s control. For the EIC7700X, Eswin has used two DDR controllers, each with two 16-bit subchannels. On the SiFive Premier P550 development board, they connect to 16 GB of LPDDR5-6400. The memory controllers run at 1/4 of the SDRAM clock, which is 800 MHz. DRAM loading has poor latency, at 194 nanoseconds, which is about 165 nanoseconds higher than L3 latency. It is unclear how much of this latency comes from traversing the on-chip network and how much comes from the memory controller. Regardless, the memory latency on the EIC7700X is significantly worse than other LPDDR5 setups, such as Intel’s Meteor Lake or AMD’s Van Gogh (Steam Deck SoC).
I measured a DRAM bandwidth of 16.74 GB/s, which is far below the bandwidth that LPDDR5-6400 can achieve even on a 64-bit bus. The EIC7700X uses some bus width for inline ECC, but even accounting for that, the actual bandwidth is far below the theoretical value. However, this bandwidth should suffice for a low-clocked quad-core setup without vector capabilities.
Core-to-Core Latency
In rare cases, the interconnect may need to perform cross-core transfers to maintain cache coherence. Eswin’s EIC7700X datasheet states that the memory subsystem has a “directory-based coherence manager,” meaning memory accesses check the directory to determine if probes need to be sent or if they can proceed normally along the memory hierarchy. Compared to a broadcast strategy, using a directory can control probe traffic as the number of cores increases.
Anandtech and other sites use “core-to-core” latency tests to check how long it takes for one core to observe a write from another core, and I also wrote my own version of the test. While the exact methods differ, the results should be roughly comparable to Anandtech’s findings. The core-to-core latency on the EIC7700X is quite high.
Even transferring between A75 and A55 cores, Qualcomm’s Snapdragon 670 performs better.
While the higher core-to-core latency is unlikely to affect application performance, it does give the impression that SiFive’s P550 is less refined.
Final Thoughts
RISC-V is a young instruction set, and SiFive is a new player in the CPU design industry. High-performance CPU design is highly challenging, as evidenced by the small number of participants in the field. According to the company’s datasheet, the P550 aims to “achieve the highest performance within strict power and area constraints.” It will not directly compete with products like AMD’s Zen 5, Intel’s Lion Cove, or Qualcomm’s Oryon. The P550’s out-of-order engine is more akin to Intel’s Core 2 from 15 years ago in size. Coupled with a much lower clock speed than Core 2, the P550 is effectively a low-power core with moderate performance. It is best suited for lightweight management tasks, where in-order cores may be somewhat sluggish.
More importantly, the P550 is a stepping stone for SiFive to push RISC-V towards higher performance goals. Not long ago, SiFive primarily focused on tiny in-order cores that were unsuitable for anything beyond microcontrollers. With the P550, SiFive has built a reasonably balanced out-of-order engine supported by a powerful cache hierarchy. They have grasped the fundamentals, which is crucial, and it cannot be overstated. It has been proven that out-of-order execution is essential for building high-performance general-purpose CPUs, but it is also difficult to achieve. In fact, both Intel and IBM attempted to abandon out-of-order execution due to the added complexity, only to find that the strategies for Itanium and POWER6 were not effective. With this in mind, SiFive’s progress is encouraging.
However, the P550 is just the first step in SiFive’s journey to build higher-performance RISC-V cores. As a step in this journey, the P550 feels more like one of Arm’s early out-of-order designs, such as the Cortex A57. By the time the A75 was released, Arm had accumulated extensive experience in designing out-of-order CPUs. Therefore, aside from the obvious sacrifices required for low power and thermal budgets, the A75 is a well-rounded and fully-featured core. In contrast, the P550’s edges are rougher. Its clock speed is low. The penalties for unaligned accesses are outrageous. There is a lack of vector support. Many programs may not encounter the P550’s most severe flaws, but SiFive has a long way to go.
In this regard, I also see similarities between the P550 and Intel’s first out-of-order CPU. The Pentium Pro from the mid-1990s performed poorly when running 16-bit code. But despite lacking polish in some important areas, the entire core design was solid enough to give Intel the confidence to tackle more complex CPU designs. SiFive has since announced more complex out-of-order designs like the P870. I look forward to seeing these cores implemented in upcoming chips as they look very promising.
Reference Links
https://chipsandcheese.com/p/inside-sifives-p550-microarchitecture
END
👇Recommended WeChat Official Account for Semiconductor Excellence👇
▲Click the card above to follow
Focusing on more original content in the semiconductor field
▲Click the card above to follow
Follow the global semiconductor industry trends and dynamics
*Disclaimer: This article is original by the author. The content of the article is the author’s personal opinion, and Semiconductor Industry Observation reprints it only to convey a different perspective, which does not represent Semiconductor Industry Observation’s endorsement or support for this opinion. If there are any objections, please feel free to contact Semiconductor Industry Observation.
Today marks the 4019th issue shared by “Semiconductor Industry Observation”. Welcome to follow.
Recommended Reading
★A Chip That Changed the World
★U.S. Secretary of Commerce: Huawei’s Chips Are Not That Advanced
★“ASML New Lithography Machine, Too Expensive!”
★The Quiet Rise of Nvidia’s New Competitors
★Chip Crash, All Blame Trump
★Alternative to EUV Lithography, New Solutions Announced!
★Semiconductor Equipment Giants, Salaries Soared by 40%
★Foreign Media: The U.S. Will Propose Banning Chinese-Made Automotive Software and Hardware