Posts Tagged ‘scenario model’
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.
(more…)
Tags: Breker, constrained-random, emulation, formal analysis, functional verification, graph, integration verification, IP, scenario model, SoC verification, TrekSoC, TrekSoC-Si, verification IP
No Comments »
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.
(more…)
Tags: analysis, Breker, emulation, formal, FPGA, functional verification, graph, IP, jasper, Kranen, scenario model, simulation, SoC verification, test generation, TrekSoC, TrekSoC-Si
No Comments »
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.
(more…)
Tags: Breker, EDA, functional verification, graph, reuse, scenario model, SoC verification, Trek, TrekSoC, TrekSoC-Si, verification IP, VIP
No Comments »
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.
(more…)
Tags: Breker, functional verification, integration verification, IP, reuse, scenario model, SoC verification, subsystem, use cases, verification IP, vertical, VIP
No Comments »
Tuesday, October 1st, 2013
Last week our friends at Cadence held the grandly named System-to-Silicon Summit not in some grand hotel, but rather at their San Jose offices. While Breker folks of course were not invited, we were curious as to how much SoC verification was addressed. Fortunately, Cadence writer and EDA legend Richard Goering has provided a very nice summary of a panel at the event dealing very much with topics of interest to us and our customers.
Within three paragraphs of Richard’s article, journalist Brian Bailey is already talking about top-down verification with “use cases.” Cadence’s Ziv Binyamini continued the topic by saying “the only way to define the requirements is against the use cases.” Jim Hogan mentioned “scenarios” for defining system behavior. There was also discussion about use cases being valuable for embedded software as well as hardware. To anyone who knows anything about Breker, this all sounds very familiar.
(more…)
Tags: application scenario, Breker, Cadence, functional verification, scenario model, test case, test generation, top-down, use cases
No Comments »
Tuesday, September 10th, 2013
In our last technical blog post, we surveyed some of the existing forms of coverage, including their virtues and limitations, and their applicability to SoC designs. We also introduced a new type of metric, system coverage, based on application scenarios that reflect how an end user would actually run applications on the SoC. We closed by claiming that “Breker’s graph-based scenario models are ideal for establishing, measuring, and refining system coverage.” This is the next in a series of posts to explain why and how.
Another earlier post described the Breker approach of “beginning with the end in mind” using graph-based scenario models. In the graphs used by TrekSoC, outcomes appear on the left and inputs appear on the right, reflecting the way that the test case generator works from the desired result toward the setup conditions needed for a particular application scenario.
(more…)
Tags: Breker, functional verification, graph, scenario model, SoC verification, system coverage, test generation, TrekSoC
No Comments »
Monday, August 19th, 2013
No SoC verification engineer worthy of the title would argue that coverage is unimportant. Even back in the 1980s, before commercial coverage tools and industry standards were available, leading ASIC teams manually added coverage code into their testbenches. They checked that key state machines visited all legal states or made all legal transitions, or that a processor executed all opcodes in its instruction set, over the course of a simulation test.
Verification teams who ignored coverage in those days were at risk of letting bugs slip through to silicon. The old maxim “if you don’t verify it, it’s broken” summed the situation up well. Today, leading SoC teams have adopted system coverage. Those who are ignoring this aspect of coverage are at risk of letting serious system-level bugs slip through. Let’s talk about system coverage and why it’s different from other metrics in use today.
(more…)
Tags: Breker, code coverage, concurrency, coverage, functional coverage, functional verification, graph, scenario model, SoC verification, system coverage, TrekSoC
2 Comments »
Tuesday, July 23rd, 2013
Folks who have been following Breker for a while know that we like the phrase “begin with the end in mind.” It succinctly summarizes why our use of graph-based scenario models is different than traditional constrained-random testbenches.
Suppose that you want to trigger a particular behavior within your design as part of your verification process. With a testbench, you have control over only the design’s inputs, so you might issue a series of input stimulus changes that you believe will cause the desired behavior. You may hit your target, or you may not. Automating your testbench with the constrained-random capabilities of the Universal Verification Methodology (UVM) reduces the manual effort, but there’s still no guarantee that you will trigger your targeted behavior.
(more…)
Tags: Breker, constrained-random, EDA, functional verification, graph, scenario model, test generation, TrekSoC, uvm
No Comments »
|
