Miniaturization of devices has led to packing more
functionality on the given slice of silicon. An after effect of that is heating
of the device due to increased power consumption and discovering innovative
ways of cooling off these components. As electronics adopted wireless, the
concern on power came to forefront as, who wants to recharge the battery every
second hour. Different techniques have been adopted since then to address this
growing concern. One such technique is letting parts of silicon go to into
hibernation and trigger a wake up when needed. My hibernation from blogging was
no different except that though I received many pokes during this time probably
the trigger wasn’t effective enough to tantalize the antennas of the blogger in
me. It was only during a recent verification event hosted by Mentor Graphics
when my friend Ruchir Dixit, Technical Director – India at Mentor Graphics introduced
the event with an interesting thought touching the basics of verification. The
message completely resonates the idea of this blog of exploring verification
randomly but rooted on basics and I took it as a sign to get the ball rolling
again. To start with, I am sharing the thoughts that actuated this restart.
Thank you Ruchir for allowing me to share the same.
 |
| Source: Slides from Ruchir Dixit - 'Verification Focus & Vision' presented at Verification Forum, Mentor Graphics, India |
Before we unfold the topic further have you ever thought as
to why computers only spell out ERRORS & not MISTAKES?
Let’s start with understanding the basic difference between an
error & a mistake. A mistake is usually a choice that turns out to be
wrong because the outcome is wrong. Mistakes are made when a free choice
is made either accidentally or performance based but can be prevented or
corrected. An error, on the other hand, is a violation of a golden reference or
set of rules that would have lead to a different action and outcome. Errors typically are a result of
lack of knowledge and not choice. That is the reason that computer doesn’t make
mistakes and only throws error on screen when unable to move forward on a
pre-defined set of actions or sees a violation to them. And that is again a
reason why you see Warnings & Errors from our EDA tools and not Mistakes :) Machines don’t make
mistakes… we do!
Now talking about verification, the sole reason of why we
verify is BUGS! And the source of these BUGS are the ERRORS & MISTAKES
committed as part of code development.
Mistakes as we understood earlier is resultant of a free
choice. While no one wants to make a bad choice, still this creeps into the
code due to distractions or coding in a hurry. To prevent or correct such
mistakes it is the basic discipline one needs to follow and that is where the
EDA tools come to rescue in assisting you to make the right choice.
Errors typically happen due to ignorance about the subject
or partial knowledge leading to wrong assumptions. This could further
find it roots in incomplete documentation or incorrect understanding of the
subject. Given that documentation & the resulting conclusions are more
subjective it is hard to define the right way to document anything. The only
way to minimize errors is to prevent them from occurring by defining clear set
of rules that need to be followed and that is where ‘Methodology’ comes into
picture. A classic example of the same is having a template generator for UVM
code to ensure the code is correct by construction & integrates seamlessly
at different levels. Having coding guidelines is another way to reduce errors.
Uncovering the rest of the errors is where the tests become important and unless
we stimulate that scenario we may not know what & where the error is.
So while errors & mistakes are unavoidable, it is the
deployment of the right set of methodologies and tools that leads to a bug free
silicon …. In time…. Every time!
After writing this post, I was tempted to say that ‘To ERR is
HUMAN and to FORGIVE or VERIFY is DIVINE!
But then that would be a MISTAKE again :)
Happy Bug Hunting!!!
Disclaimer: “The postings on this blog are my own and not
necessarily reflect the views of Aricent”
