Thursday, December 11th, 2014
Few electronics-related topics have been more widely discussed in the past year or so than the prospects for the so-called Internet of Things (IoT), sometimes called the Internet of Everything (IoE). Hardware and software vendors have been falling all over themselves trying to ride the presumed IoT juggernaut. EDA has not been immune. In its roundup of attendee feedback from this year’s Design Automation Conference (DAC), the DeepChip site quoted a user saying, “The ubiquity of IoT. After 6 hours into DAC, I was ready to slap the next vendor who used that buzzword.”
The trumpeting of IoT was even greater at ARM TechCon, not surprising because of its focus on embedded systems. Here at Breker, we’ve used the term sparingly because it’s not really clear exactly what the IoT will become. Certainly there will be many more nodes of all sorts connected to the Internet in coming years, but there are numerous open questions. Our main interest is whether the IoT will result in an explosion of new SoC designs, and hence a broader market for our verification solutions. This blog post doesn’t provide a firm answer since none is possible yet, but it’s a topic worth addressing.
Tuesday, December 2nd, 2014
This blog focuses mostly on verification, but from time to time we like to take a look at other aspects of the EDA industry. Today we’d like to discuss high-level synthesis (HLS), its progress and status, and what’s keeping it from being a mainstream technology used for every chip design. It turns out that this topic has a lot to do with verification, so we’re not straying too far from our primary focus.
To start, let’s define what we mean by HLS in contrast to the mainstream technology of logic synthesis. Generating gates from a hardware description language (HDL) moved from a research problem to viable products around 1988. The ultimate winner among several promising companies was Synopsys, in part because they chose a register-transfer level (RTL) subset of the popular Verilog HDL as their input format. Their tools generated a gate-level netlist using the cells available in an ASIC vendor’s library.
Tuesday, November 25th, 2014
Yes, we know that the title of this week’s post sounds a lot like two previous posts. We wanted to link together the two threads from those posts into a single message that we believe reflects what is happening right now in the world of complex chips. This is a short summary in line with the short week due to the Thanksgiving holiday here in the United States. The line of argument is straightforward:
- Large chips are adding embedded processors to implement complex functionality while retaining flexibility
- Single-processor chips are adding multiprocessor clusters to get better performance at a given process node
- Multiprocessor chips are using shared memory for effective data transfer and interprocess communication
- Neighbor-connected processor arrays are moving to shared memory to reduce cross-chip data latency
- Multiprocessor designs are adding caches to reduce memory access time and bypass memory bottlenecks
- Multiprocessors with caches require coherency in order to ensure that the right data is always accessed
While most of these statements are not universally true, they reflect a significant sea change that we see every day when discussing current and future projects with our customers.
Tuesday, November 18th, 2014
In last week’s blog post, we talked about the emergence of the commercial IP industry and shared some personal experiences. Although Breker is an EDA company and not known for IP products, we intersect with semiconductor IP (SIP) and verification IP (VIP) in important ways as we work with our customers. We’re also starting to offer our own scenario model IP (SMIP) as part of accelerating and improving verification even more. We’d like to expand on these topics in today’s post.
We have few if any customers or prospective customers who don’t use commercial VIP in their testbenches. After all, if you’re designing a standard interface you want the best verification possible that you’re meeting the standard. A VIP model that’s been used by dozens or hundreds of other projects serves as a pre-silicon “plugfest” where you get to verify your implementation of the standard against what others have done. Now that the Universal Verification Methodology (UVM) is nearly ubiquitous, most VIP is developed in a fairly consistent manner.
Thursday, November 13th, 2014
In my recent report from the Silicon Valley IP Users Conference, I passed on the prediction that the compound annual growth rate (CAGR) of semiconductor (SIP) is expected to be 12% for the next five years. Clearly there is a growing need for portions of huge SoCs to be pre-designed, pre-verified, and delivered as reusable SIP. This is a trend that started about 20 years ago with the earliest SIP vendors selling libraries and cores for standardized functions along with verification IP (VIP) to support their use.
The IP (SIP and VIP) industry has evolved a lot since then. The most obvious change is that it has been largely consumed by the major EDA companies. Synopsys and Cadence, in particular, have made many acquisitions in this space over the past few years. Some of the price tags have been quite impressive: US$380M for Tensilica, US$315M for Virage, and about the same price for Denali. In this post, I’d like to share some thoughts on the evolution of the IP business.
Wednesday, November 5th, 2014
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.
Thursday, October 30th, 2014
In last week’s post, we discussed in detail how Breker’s TrekSoC and TrekSoC-Si products can verify the performance of your SoC by stressing every aspect of its functionality. Shortly before that, we announced a partnership with Carbon Design Systems to complement their fast, accurate processor models with TrekSoC. About two months ago, we introduced the new Coherency TrekApp and described how it can verify multi-processor cache coherency with minimal effort.
You can see a strong theme here: multi-processor SoC designs, fast simulation models, automatic generation of multi-threaded, multi-processor test cases, and test cases powerful enough to gather realistic performance metrics from pre-silicon simulation. But what if you don’t have multiple processors or caches in your SoC design? There’s a clear sense emerging in the industry that more and more chips are becoming multi-processor SoCs, and most of these will require cache coherency for the CPU clusters and beyond. Let’s explore this topic more in this post.
Wednesday, October 22nd, 2014
For those unfamiliar with the expression in the title, bringing someone (or something) to its knees means making it submissive. It’s a metaphor possibly derived from the act of hitting someone so hard that his knees buckle and he falls to a kneeling position. Why such a nasty term to start this post? Because when you want to verify the performance of your SoC you want to stress every aspect of it. You want to be mean to it. You want to bring it to its knees.
The most common way to do this is to run production software (operating systems plus applications) on a virtual prototype, a high-level system model created by architects before RTL implementation begins. This is not easy; it takes effort to set up workloads that will stress the design and often production software is not ready at this early stage of the SoC project. Further, this verifies only the high-level model, but RTL simulates too slowly to replicate the same tests, or often to boot the operating system at all.
Thursday, October 16th, 2014
I spent Tuesday of this week in the Winchester Mystery House, San Jose’s best-known tourist attraction, hearing a wide variety of opinions about design IP, verification IP (VIP), the Internet of Things (IoT), and related topics. “Unlock the Mystery of IP: Silicon Valley IP Users Conference” was organized and presented by IPextreme and their Constellations program partners. I found most of the talks quite interesting, and would like to share some thoughts on what the experts’ projections might mean for Breker and our customers.
There is no doubt that the increasing use of IP is key to designing ever larger chips. Kands Manickam of IPextreme noted that, over the next five years, the compound annual growth rate (CAGR) of IP blocks and subsystems is expected to be 12% versus 3.5% for semiconductors. Randy Smith of Sonics reported that the average large chip today has about 120 blocks, growing to more than 200 by 2018. We already know that VIP reuse is not as effective as design IP reuse, and these projections will only exacerbate the gap.
Wednesday, October 8th, 2014
Last week we summarized some of the activities at the inaugural DVCon India. Breker was not the only company impressed by this show. For example, CVC wrote two posts on their VerifNews blog describing the excitement and range of technical content at the show. Gaurav Jalan captured several aspects of the show in his Sid’dha-karana blog, focusing specifically on the keynote speakers. The Agnisys blog also provided a nice overview. Clearly this was a very successful event.
The high quality of the technical content and the excellent attendance at DVCon lead me to think about how much India has changed in just a few years. I first had an engineering team there in 1995, nearly 20 years ago. I recall my first trip to India very well and the contrast with recent visits is tremendous. I’ve been deeply impressed by the evolution of electronics development in India and I see the DVCon success as both a tribute to where the community is today and a sign of even better things to come.