Sunday, February 18, 2018

Moana of Verification!!!

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???


  1. hello sir,
    Thanks 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

    1. Shobana you may write to me on what exactly you are looking for & let's figure out the solution to that. (

  2. Hi Gaurav , good to see you on siddhakarana again. Publish on SoC side also.

  3. Hi Gaurav, good to see you back on siddhakarana.publish on SoC side also

    1. Sure. Just in case if you haven't checked -

  4. Hello sir,
    I have a doubt for loop oscillation in combo logic, can we do simulation in zero delay? With sdf it will resolve. But without sdf?

  5. Hello boss,
    I 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.

  6. Tarun,

    Do 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.