Let me start by laying the cards on the table – the Portable Stimulus Standard (PSS) is a language, not a methodology. Tools are not methodologies. Languages ensure a well-ordered transfer of information from which tools can be constructed. A methodology is a way of systematically breaking down and solving a problem in a manageable manner. Tools can enable methodologies, and, over time, tools may help to manage a methodology once it has become standardized. No standard methodologies exist today for PSS, neither are the capabilities of tools defined by the language. (more…)
The Breker Trekker
Posts Tagged ‘functional coverage’
Methodology, Language and Tools
Tuesday, January 15th, 2019Industry Struggles with System Coverage
Thursday, March 15th, 2018DVCon is a great place to talk to design and verification engineers. As the Accellera Portable Stimulus Standard (PSS) gets closer to reality, we were able to share with them during the conference the progress made and the ways in which it may impact their task. Most of them are as excited about PSS as we are. While we have been working in this field for more than a decade and have received a lot of feedback, there are now many more people becoming aware of it and the potential that it has. This provides us with the opportunity to learn as well. (more…)
Designers and Verification Engineers: Living in Different Worlds Together
Tuesday, April 19th, 2016As I discussed at last week, there are many different engineering roles involved in the development of a large, complex semiconductor device. The EDA industry attempts to serve nearly all of these groups, from the architects and product marketing engineers who dream up the new ideas to the technicians who test production parts on the factory floor. Today I’m focusing on the work of two of EDA’s most traditional customer bases: hardware designers and hardware verification engineers.
Perhaps I’d better explain my title. It comes from an old expression “we went to different schools together” that I remember hearing as a youngster. Sometimes this refers to two people who didn’t actually attend the same school but who are nevertheless longtime close friends. But I’ve also heard it used to refer to two people who did in fact go to school together but had very different experiences. This latter context is the one I have mind for design and verification engineers who work on the same project yet inhabit different worlds.
If You’re Not Measuring System Coverage, Your SoC Is at Risk
Monday, August 19th, 2013No 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.
