Last week’s post was addressed primarily to those of you who are already designing SoCs. We made the point that more and more SoCs have multiple processors, either homogenous or heterogeneous, and that most or all of those processors do or will have caches. This led to the main conclusions of the post, that multi-processor cache coherency is necessary for most SoCs, and therefore that coherency is now a problem extending beyond CPU developers to many chip-level verification teams.
But what if you don’t have embedded processors in your design? There’s a clear sense emerging in the industry that more and more types of chips are becoming multi-processor SoCs, and most of these will require cache coherency for the CPU clusters and beyond. In this post we’ll describe the trends we see, based in part on what we learned at the recent Linley Processor Conference in Santa Clara. The world as we know it is changing rapidly, offering more challenges for verification teams but more opportunities for us to help.
Some types of chips have had embedded processors for some time. SoCs are the norm in many types of consumer devices: smart phones, tablets, cameras, printers, and more. Many people believe that the Internet of Things (IoT), sometimes known as The Internet of Everything (IoE), will be the next big driver for the SoC market. IoT chips are likely to look like smaller versions of consumer SoCs, with one or more processors, wireless connectivity, and sensors to gather real-world input.
As we mentioned last week, many SoCs have evolved to add multiple processors and many of these processors have caches, driving the need for cache coherency. We noted that many smart phones and other consumer devices already contain multiple embedded processors, and it’s just a matter of time before they contain multi-level, coherent caches. That’s why we made the claim that “if your SoC is not cache coherent, it soon will be.”
As suggested by the title of this week’s post, we believe that other types of chips are following suit. Networking chips (routers, switches, bridges, modems, etc.) have traditionally not relied on CPUs for their main functionality. They might have contained a control processor to configure the chip and handle exceptions, but generally this processor was not involved in the main flow of data through the chip. The chip could be verified by a traditional UVM testbench without writing test cases to run on the embedded processor.
Many networking chips are becoming true SoCs, with multiple processors, and soon many of them will have coherent cache structures as well. The Linley conference featured more than two dozen interesting talks on new and upcoming chips for a wide variety of applications. What was surprising to the Breker attendees is that many of the block diagrams looked rather similar, with multiple processors and multi-level caches. Their need for cache coherency and processor-based performance metrics is looking much like other SoCs.
Embedded processor IP vendors are delivering self-contained CPU clusters, as shown on the left, and SoC teams are incorporating them into chips as shown on the right. Traditional SoC such as those for cell phones and tablets are clearly moving in this direction. However, we’re also seeing that the networking “sea of processors” or “array of processors” in a mesh-connected structure with no shared memory is giving way to fully cache-coherent multi-core designs that look much like these two diagrams.
So, we end up at the same place that we ended last week. Chips are moving to SoCs and SoCs are demanding multi-processor cache coherency. TrekSoC and our Coherency TrekApp are out-of-the-box solutions for verifying pre-silicon multi-processor cache coherency and measuring performance under realistic system stress. TrekSoC-Si extends these benefits to hardware platforms (emulators, FPGA prototypes, and silicon in the lab) all the way to post-silicon validation. As always, please contact us to learn more.
This is a guest post by Tom Anderson which is vice president of Marketing for Breker Verification Systems. This post originally appeared on The Breker Trekker blog at EDACafe.
