Tuesday, December 17th, 2013
With due apologies to Barbra Streisand, the topic of today’s blog post is the verification of SoC memories and memory subsystems. Once upon a time, memories were considered just about the easiest design structure to verify. A simple automated test doing “walking 1s” and “walking 0s” supplemented by some random reads and write to random addresses with random data seemed to be good enough.
“Can it be that it was all so simple then? Or has time re-written every line?” Actually, it really was that simple back then. But a lot of changes in memory subsystems have come along to complicate matters: memory regions, caches, multi-processor designs, shared memory, complex memory maps, etc. Verification of memories today is much more challenging, with many corner cases to be exercised, but it’s an essential part of the overall SoC verification effort.
Tuesday, December 10th, 2013
As you likely know by now, Breker’s primary focus is on verifying SoCs with one or more embedded processors. Sometimes these processors are homogenous, most commonly either the Intel/AMD x86 or ARM architecture. Other SoCs have multiple heterogeneous processors, possibly a diverse mix of cores from x86, ARM, MIPS, ARC, Tensilica, etc.
The trade press devotes a lot of virtual ink to covering the “war” for embedded processor dominance. An article last week made the case for ARM winning. A recent white paper discussed “heterogeneous multi-processing” using ARM’s “big.LITTLE” approach of multiple cores with the same architecture but different performance characteristics. Another article reminded us not to forget about DSPs in the heterogeneous mix. The same could be written about GPUs. So what is Breker’s take on all this?
Wednesday, December 4th, 2013
As I hoped, my recent post challenging Jasper Design Automation’s statement that “formal will dominate verification” has drawn very good readership and generated some stimulating industry discussions. Today, Joe Hupcey III from Jasper responds and offers more ammunition for their claims of dramatic recent advances in the power and usability of formal technology:
Thanks to the folks at Breker for the comments and analysis in your post asking “Will Formal Really Dominate Verification?” in reference to Jasper’s recent assertion of formal’s ascendancy. As your thoughtful post acknowledges, verifiers are seeing formal starting to take over block and unit level verification, as well as select system-level applications. Indeed, the industry has seen this movie twice before – specifically, the growth of emulation into the mainstream and again with constrained-random simulation.
Tuesday, November 26th, 2013
The Breker Trekker has been publishing for about seven months now, with 32 posts to date, so running just about once a week. When we started, we committed a new post every two weeks so we’ve been running well ahead of our own expectations. We’re very happy with the growth of our readership and we’d like to take this chance to thank every one of you reading this.
Frankly, we have not been as successful at driving an ongoing dialogue via comments. We’ve had a few comments here and there but not nearly as many as we would like to see. So for this week’s post we’re trying something different: posing a question directly to our readers and heartily encouraging all of you to share your thoughts by leaving a comment at the bottom. Today’s topic: which conferences and trade shows do you find most useful?
Tuesday, November 19th, 2013
In last week’s post, I responded to an article in which Jasper‘s CEO is quoted as saying “formal will dominate verification” and that concluded “at some point in the future, formal will be the default choice for every verification task in the way that simulation/emulation is today.” I challenged this statement, giving examples of SoC verification where I do not believe that formal analysis alone can provide the answer.
Thinking about formal in that way naturally led me to ask the same question about Breker’s technology. Will graph-based scenario models “dominate verification?” At some point in the future, will graph-based scenario models “be the default choice for every verification task in the way that simulation/emulation is today?” As I promised last week, I’ll offer my thoughts on these questions as well.
Wednesday, November 13th, 2013
Today’s post is prompted by a recent article on SemiWiki in which Jasper Design Automation’s CEO Kathryn Kranen is quoted as saying “formal will dominate verification.” There is a nice set of metrics from Jasper’s recent User Group meeting showing their impressive growth in revenue, logos, users, and licenses as supporting evidence for formal’s increasing footprint. The article concludes by stating “at some point in the future, formal will be the default choice for every verification task in the way that simulation/emulation is today.”
That made me sit up and take notice. Before joining Breker, I spent the previous 12 years of my career focusing on formal analysis, about six years full-time and the rest as one component of a wider suite of verification products I managed. I’m a big fan of formal, but I don’t think that I can comfortably predict that it will “dominate” verification. Let me share my thoughts.
Monday, October 28th, 2013
Over the last couple of decades, vendor-specific conferences have complemented and in some markets even supplanted general industry events. Intel, Microsoft, Sun/Oracle, Apple, and many other companies have had huge, successful shows year after year. Perhaps it’s a sign of a certain level of maturity when a company has the resources to hold its own event and the appeal to attract a large crowd.
In the world of EDA (and IP, and embedded systems), ARM is certainly one of the biggest recent success stories. As the company has grown, its small technical events have evolved into a major show now known as ARM TechCon. Breker will be both speaking and exhibiting at this week’s event in Santa Clara, just down the road from Breker’s headquarters in San Jose.
Monday, October 21st, 2013
Breker customers have surely noticed that the quantity and quality of our product documentation have taken a huge leap in the last six months or so. This is due to the Herculean efforts of Bob Widman, a well-known documentation, training, and applications expert in the EDA industry. He has been working with Breker for most of this year and the results speak for themselves. We’re pleased that Bob has contributed the following guest post on the importance of documentation:
Why does a company provide documentation with its product? The typical answer is that the customer expects it. Often overlooked is how the process of creating the documentation has a positive impact on the product and the company that is developing it.
Tuesday, October 15th, 2013
All of us at Breker are excited as we write this post, since we’ve just made our most important product announcement in several years. We’ve expanded the Breker product line by adding TrekSoC-Si, a brand-new tool that generates multi-threaded, multi-processor, self-verifying C test cases for in-circuit emulation (ICE), FPGA-based prototypes, and actual production silicon. In other words, TrekSoC-Si does for hardware platforms what TrekSoC did for simulation.
We’ll talk more about how TrekSoC-Si works in a moment. But first it’s important to note that both TrekSoC and TrekSoC-Si use the same graph-based scenario models as input to describe the intended behavior of the SoC and provide a test plan. This means that, for the first time in the industry, you can achieve horizontal verification reuse across your entire project schedule, from high-level simulation models all the way through your first chips arriving from the foundry.
Tuesday, October 8th, 2013
One of the curious aspects of electronics is that most products are specified from the top down but implemented and verified from the bottom up. This is true for system-on-chip (SoC) development as well. As the onset, someone in product marketing specifies a chip that has a specific collection of functionality to meet a specific customer need. The architecture team develops a block diagram that defines the subsystems and perhaps some individual IP blocks as well.
When it comes time to develop the RTL that implements the SoC, designers tend to work from the IP blocks upward. They select commercial IP where it makes sense and develop unique IP when needed. Designers are usually responsible for verifying their own blocks, perhaps with some assistance from verification engineers. There is usually minimal verification of commercial IP unless it has been customized for the SoC project.