Dear Readers!!!! Welcome back!!!
During this lull period of sharing thoughts, I realized
that even blogging faces the same dilemma of verification on “How much is
enough”. Finally, as a verification engineer should think, I decided to
continue as much as I can with the hope to improve blogging frequency than
before – wish there was Moore’s law for
bloggers too 😊!!! Since this is the first one of this year
(Happy New year folks!!!) & by this time of the year the intent, action and
discussions on new year resolutions would have died down mostly, let’s start
from there. While speaking to budding DV
engineers on their new year resolutions around verification, I discovered that
somehow focus on the end goal is missing & they seem to be trending into
all directions. Reason? Well! Possibly many –
- The never ending gap between industry expectations &
Academia.
- Missing core elements in the Job description of a
verification engineers.
- Overwhelming solutions that enable verification….. etc.
Still confused on what I mean? Let me explain!
When I started my career as a verification engineer with
legacy directed verification approaches, all I learnt was that, to be
successful you need to have - a Nose for Bugs! In a way, that was also
because one needed to maximize returns from each test so, you handcraft each one to
really mine bugs. With rising silicon complexity, verification domain has been
experiencing consistent advancements enabling us verify designs faster & better.
During this shift, the expectations from verification engineers also kept
changing i.e. demanding experience on new flow, language or methodology. The rise
of SV & UVM further accelerated this shift giving a taste of elaborate
& sometimes exotic code development opportunities for the DV engineers.
While this continued, reuse gained momentum on the design & eventually on
verification too. Due to this the code development gave way to reuse & with
latest verification flow/methodologies, the verification engineers started
spending more time on derivative designs that demand debug capabilities over
development.
Coming back to our budding engineers discussion, learning
a new flow/methodology would end up having expectations on development work
which may not really be needed always. This trend has often lead to the confusion of
multiple directions where the engineer ends up settling on the means losing focus on the end goal. As a DV engineer, our goal
is to find bugs! Approaches like Directed/Constrained Random/Formal or
languages, methodologies & platforms like simulator/emulator etc. are all
means to hunt bugs. While expertise in many or all of these are
important and occasionally may even lead to a career, the expectations from
verification engineer is really to catch bugs!
How does this relate to the topic of the blog?
Well! Moana is a film on the story of a girl named Moana,
daughter of a chief of a Polynesian village.
She is chosen by the ocean to reunite a mystical relic with a goddess. When a blight strikes
her island, Moana sets sail in search of Maui, a legendary shapeshifting demigod,
in the hope of returning the heart of Te Fiti and saving her people. In this
journey of hers, she discovers that her tribe were ‘voyagers’ who have
forgotten their virtue and settled as villagers on an island which would die
down soon. She not only saves the island & her people but leads them back
to their original self – a journey which is more exciting & enriching!
Similarly, UVM, formal apps and emulation etc. are all
means to find bugs in your verification journey. Don’t just settle for the
means which might be short-lived sometimes but shoot for the end goal & be the Moana of Verification!!! A worthy
resolution to pursue 😊!!!
What was your resolution on verification on this New Year???
hello sir,
ReplyDeleteThanks for sharing wonderful information.
can you please help me to understand more on GLS and best resources for it
as i am not having any hands on how i can practice on my own
Thanks
Shobana you may write to me on what exactly you are looking for & let's figure out the solution to that. (siddhakarana@gmail.com)
Deleteawsome, specially nose for bugs!!!
ReplyDelete:)
DeleteHi Gaurav , good to see you on siddhakarana again. Publish on SoC side also.
ReplyDeleteHi Gaurav, good to see you back on siddhakarana.publish on SoC side also
ReplyDeleteSure. Just in case if you haven't checked -
Deletehttp://whatisverification.blogspot.in/2011/03/what-makes-optimal-soc-verification.html
Hello sir,
ReplyDeleteI have a doubt for loop oscillation in combo logic, can we do simulation in zero delay? With sdf it will resolve. But without sdf?
Hello boss,
ReplyDeleteI have a doubt, can we do simulation when we are getting loop oscillation in zero delay. Is there any method for combinational logic loop. With sdf it will resolve.
Tarun,
ReplyDeleteDo you mean can we continue with simulation when we end up in a loop with zero delay? Ans: This is like an infinite loop. So, why would you want to simulate that!
If you encountered this during netlist simulations & want to study the behavior of the circuit - try unit delay.
Typically combinational loops should be avoided for reliability of the circuit.