The Beginning Of The End For Coverage

Posted by 
in Blogs
03 June 2019

Before we get started here, I’ll assure you it’s not as it sounds. I’m not talking about the end of coverage as though it’s something we’ll stop using. The end in this case is the home stretch of any non-trivial ASIC or FPGA development effort – which is almost all of them nowadays – where coverage collection, analysis and reporting consumes a team on its way to RTL signoff.

The beginning of that end is something we consistently ignore. In my 18 years as a verification engineer, having worked with many different development teams and organizations, I’ll admit to ignoring the beginning of coverage myself. I think we’ve become so accustomed to coverage closure being a mad scramble that we’ve long given up on the idea it can be anything else. Though if we step back to see that coverage does indeed have a beginning, we’ll see it also has a flow. And it’s the flow that’ll ultimately save us from the mad scramble long perpetuated in semiconductor development, growing in strength since the late 1990’s when functional coverage first became a thing.

The Beginning

In The Beginning… there was no code, no tests nor environment; there were only verification engineers and they were saying it’s going to be a while before they can show any progress because it takes a hell of a long time to build a constrained random environment. And besides, the RTL isn’t ready yet anyway. This is where the mad scramble starts; it’s the fact development takes time paired with the idea that progress during the active development phase of a project isn’t tangible enough to measure with coverage.

The first step toward avoiding the scramble is to change that early development mindset. Progress can’t be a gut feel from a black hole captured as a few lines in a status report. It needs to be tangible; a statistic, with history, that trends over time to guide decision making and objectively sheds light on the reality of our current state not to mention the delivery dates we all agree to. Which brings us to our purpose in The Beginning: capturing coverage trends that assist with objective decision making later on.

With literally everything left to do, statistics and trends can’t be yet another burden on the team. Luckily, code coverage fits the bill because we essentially get it for free. So The Beginning of coverage is easy; it’s configuring a regular regression with the code coverage enabled on day 1 with a dashboard for publishing trends. And don’t worry if it starts with just a single test or even part of a single test. That single test will grow into a full-featured regression before you know it.

click here for the full blog post

Last modified on Sunday, 04 August 2019 12:20