The ESL Edge


Luck happens

Those who hope to be lucky rarely are. Those who plan to be lucky meet with much more success.

While you cannot make luck happen, you most certainly can stack the odds in your favor. This was a thought that came to me while trying to deal with a close family member. As a young person recently out of college, they do not yet have the skills or the maturity to make getting over the rough patches as easy as they should be. Everything becomes a much bigger hurdle than it needs to be and the here and now seems to be more important than the future.

The same is true within the high-tech industry. There are some managers who seem to have everything under control and others that rush from emergency to emergency. These are the ones who have not learn to stack the deck in their favor and then with just a little bit of luck, allow them to coast along to smooth result. There are companies too that do not seem to ever get their heads above water. We all know one of those that will be in the press a lot over the next few weeks. Did they really think things through? Did they put the contingencies in place? Did they ask the really difficult questions before they got there and had the answers ready? The way things played out, I think it is clear that they did not.

So let’s tie this to verification. It is the verification team who ultimately has the responsibility to stack that deck and then with a little bit of luck, no major bugs will have escaped. While most verification teams will cringe at the thought that they are rolling dice, that is what the dynamic verification process really is. The tools that we use and the metrics that we use to measure progress are not really related to quality at all. They do not tell us that bugs do not exist, they only tell us that we have tried enough things that with luck on our sides we will have found the bugs. If we want to stack the decks in our favor even more, we need to improve some of the fundamental aspects of our process. The one that most concerns me are the coverage metrics. We have to get away from the sole use of stimulus metrics, such as code coverage and functional coverage. We must start to use metrics that are tied to actual verification checks. In a recent CDNLive paper presentation, one speaker had come to do that in some respects through an accident (or luck). They would only record a coverage event when a checker had performed an action, either pass or fail. This was for efficiency reasons, but it was a very positive step as it now ties an act of verification to a coverage event. Any coverage event that is recorded with knowing that a positive check has been made to say that the activity was correct is dicing with danger and the more we do that, the sooner our luck will run out. In addition, functional coverage metrics are subjective in nature, which means that we have injected another area where we hope we are lucky.

In a couple of weeks, a number of people who are really concerned about this issue will be getting together at the Haifa Verification Conference. I hope that we have a good discussion that can shed some light on the way out of the situation the industry has put itself into.

One Response to “Luck happens”

  1. 1
    David Robinson Says:

    Ahh, good. It’s not just me then who’s concerned at the importance given to measuring functional coverage while checking is ignored. I wrote a blog about this a while ago ( and then a second one to fend off the comments from the first (

    Triggering the functional coverage when the check passes is a common(and the easiest that I know of) way of dealing with this problem, but many people don’t recognise it as a problem in the first place.

    I’d be interested in hearing the conclusions from the conference discussion.


Leave a Reply

© 2018 The ESL Edge | Entries (RSS) and Comments (RSS)

Design by Web4 Sudoku - Powered By Wordpress