Posts Tagged ‘constrained-random’
Tuesday, April 29th, 2014
Last week I mentioned that I attended the third “Decoding Formal Club” meeting sponsored by formal consulting experts Oski Technology. I started out to write about this event but was distracted by the big news that Cadence had acquired formal leader Jasper Design Automation for $170M. As the meeting was winding up, a friend from Mentor picked up the news alert and showed it to me. I pulled up the news on my own smartphone and showed it to Vigyan Singhal, CEO of Oski and also the original founder of Jasper.
So I had the pleasure of informing Jasper’s founder that his old company had been acquired. But I don’t want to let that bit of fun or the Jasper news in general to lead us to forget about the Decoding Formal meeting. There were two primary segments: a presentation from Vigyan on verification planning and a panel of expert users on building a formal team. I’ll talk about the presentation today and cover the panel in a future post.
Tuesday, February 18th, 2014
In our last post, we discussed the results of a survey by Wilson Research Group and Mentor Graphics. Among other interesting statistics, we learned that verification engineers spend 36% of their time on debug. This seems consistent with both previous surveys and general industry wisdom. As SoC designs get larger and more complex, the verification effort grows much faster than the design effort. The term “verification gap” seems to be on the lips of just about every industry observer and analyst.
We noted that debug can be separated into three categories: hardware, software, and infrastructure. Hardware debug involves tracking down an error in the design, usually in the RTL code. Software debug is needed when a coding mistake in production software prevents proper function. Verification infrastructure–testbenches and models of all kinds–may also contain bugs that need to be diagnosed and fixed. As promised, this post discusses some of the ways that Breker can help in all three areas.
Tuesday, February 11th, 2014
For today’s blog post, we use as our text a recent article on SemiWiki by well-known verification expert Hemendra Talesara. He provides a nice summary of a recent talk given in Austin by another verification expert, Harry Foster from Mentor. Many of you have probably seen Harry’s blog posts dissecting in great detail the results of a bi-annual survey that Mentor commissions from Wilson Research Group. There is much less coverage and analysis of the EDA world available today than there used to be, so we all applaud Mentor’s willingness to fund this survey and share the results.
Hemendra’s focus is on the well-known phenomenon of verification consuming more and more of a chip project’s resources. It is not uncommon to find that SoC projects have two or three verification engineers for every design engineer. So what do these verification engineers do with all their time and resources? The interesting result from the Mentor survey is that verification engineers spend 36% of their time on debug. At Breker, we’ve given a lot of thought about how to reduce debug time and effort, so we’d like to share some thoughts.
Tuesday, January 28th, 2014
When people first start reading about Breker and what we do, we make the point that transactional simulation testbenches are breaking down at the full-SoC level. Usually, we specifically mention the Universal Verification Methodology (UVM) standard from Accellera as not being up to the challenge of full-chip verification for SoC designs. We sometimes worry that someone will read into this that we don’t like the UVM, or Accellera, or even standards in general. Nothing could be further from the truth!
We have great respect for the UVM and other EDA-related standards developed by Accellera, IEEE, and other organizations. In this post, we’d like to discuss specifically what we see as the strengths and weaknesses of the UVM and explain how Breker’s technology complements rather than replaces this methodology. Yes, the UVM has limitations, and we address those with our tools and technologies. But the UVM forms a stable and standard base on which nearly all of our customers build their simulation-based verification environments.
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.
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 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.
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.