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

Marlin & Dory way of 'Finding Bugs'

On our return after watching ‘Finding Dory’, my son asked, “Dad, if you were to find Dory would you be able to do that”? I said, “Ofcourse”! Next, came HOW? I reminded him that my job is to Find Bugs and so I know the tricks of the game already. That made him super excited and wanting to know more about it. Given that this time the reference was picked by him, I decided to continue the same to explain him further.

In the movie, Marlin and Nemo were finding Dory inside the Marine Life Institute (MLI), likewise, we find bugs inside the design called as System on Chip (SoC). The SoC has a lot of similarity to MLI in the sense that it is big and complex. As MLI had different sections, our SoC has different blocks where Dory (Bug) can be found. Also it is not only the sections but the inter-connections that are equally important. When we look for Dory (Bug) inside these blocks we call it IP verification and when our focus is on the inter-connections we call it Integration or SoC Verification.

Image Source : http://www.socwall.com/desktop-wallpaper/7462/dory-and-marlin-by-ryone/

We start off our quest using the Marlin way i.e. “Assess the situation, evaluate, and plan it out”. We call it the Directed Verification approach wherein we understand the design, prepare a plan on where and how we would look around for Dory (Bug) and then execute accordingly. During this process we also keep asking (reviews) around (designers & peers) to let us know if we are missing out on anything. So if Dory is somewhere around, there is a chance we may sight her. But since Dory doesn’t think much before acting, that makes her unpredictable. There is always a possibility that we may not find her as per our plan.

My son’s eyeballs zoomed…. THEN?

Then we also do what Marlin & Nemo did i.e. follow “What would Dory do”? My son jumped, "She wouldn’t think twice and be random". Yes! We pick the Dory way and we call it Random Verification. We search randomly everywhere in an unplanned sequence and guess what? The chances that we would find Dory (Bug) increase. To make it more effective, we define weights and constraints to the randomness so as to improve our luck of finding her further. The approach now becomes Constrained Random Verification (CRV).  While following this random pattern we also take a note (coverage) of where all we have visited to avoid repeating same place again and save time. Now we can find her faster. Tracking coverage on top of CRV is called Coverage Driven Verification (CDV). So if we missed finding Dory (Bug) using the Marlin way (Directed verification) we still have an option to find her the Dory way (CRV).

That settled my son for a while till he pointed again saying, “Dad, maybe you should seek help from Bailey, the beluga whale who can find Dory faster than anyone using echo location”. I smirked and told him that we have our Bailey too and we call it Formal Verification. But then, Bailey was dependent on the whale voice between Dory & Destiny, the whale shark without which he couldn’t be of much help. Similarly, in Formal we are dependent on the assertions that connect the tool to the bug in the design. The effectiveness of this approach is purely dependent on the quality of voice (assertions) and the connect (covering all parts of design) between Dory & Destiny. But yes, if that is in place, it is really fast & effective.

Now convinced that his dad would be able to find Dory, my son asked, “So once you have found Dory, what do you do next”?

I laughed and told that we don’t have to find only 1 Dory (Bug). There are many of them and the address and architecture of the institute (new SoC) also keeps changing. So we just keep Finding Dory (Bug)!!!

Disclaimer: "The postings on this blog are my own and not necessarily reflects the views of Aricent"

.....of Errors & Mistakes in Verification

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”

The magical chariot in verification!

As the holiday season kicked off in India, the antennas of my brain tickled to intercept between what is going around and relate it to verification. In past, I have made an attempt to correlate off topic subjects with verification around this time every year. Dropping the mainstream sometimes helps as it gives you a different perspective and a reason to think beyond normal, to think out of the box, to see solutions in different context and apply it to yours, in this case verification! The problem statement being – driving verification closure with growing complexity and shrinking schedules.

 

Before I move forward, let me share the context of these holidays. This is the time in India when festivities are at their peak for few weeks. Celebration is in the air and the diversity in the culture makes it even more fascinating. People from all over India celebrate this season and relate it to various mythological stories while worshipping different deities. The common theme across is that in the war of good and evil, good prevails finally! What is interesting though are the different stories associated with each culture detailing these wars between good and evil. In the process of growth of the evil and the evolution of good to fight it, both tend to acquire different weapons to attack as well as defend. And when the arsenal at both ends is equally equipped, the launch-pad becomes a critical factor in arriving to a decision. Possibly, that is another reason why different deities ride different animals and some of these stories talk about those magical chariots that kind of made the difference to the war.

 

So how does this relate to verification?

 

As verification engineers our quest with bugs amidst growing complexity has made us acquire different skills. We started off with directed verification using HDLs/C/scripts and soon moved to Constrained random verification. Next we picked different coverage metrics i.e. functional, code coverage and assertions. As we marched further, we added formal apps to take care of the housekeeping items that every project needs. Almost a new tool/flow keeps adding every couple of years in line with the Moore’s law J. And now if we look back, the definition of verification as a non-overlapping concern (functional only) in the ASIC design cycle few decades ago is all set to cross roads with the then perceived orthogonal concerns (clock, power, security and software). While we continue to add a new flow, tool or methodology for each of these challenges that are rocking the verification boat, what hasn’t changed much in all these years is the platform that the verification teams continue to use. Yes, new tools and techniques are required but are these additions bringing the next leap that is needed or are they just coping up with the task at hand? Is it time to think different? Time to think beyond normal? Time to think out of the box? And if YES what could be a potential direction?
 

This is where I come back to the mythological stories wherein when the arsenal wasn’t enough; it was the magical chariot that did the trick! Yes, maybe the answer lies in bringing the change in the platform – our SIMULATORS – the workhorse of verification! Interestingly, the answers do not need to be invented. There are alternate solutions available in form VIRTUAL PROTOTYPING or using HARDWARE ACCELERATORS/EMULATORS for RTL simulations. Adopting these solutions would give an edge on both the bugs causing menace as well as the competition! And for those who think it is costly to adopt, a lost market window for the product could be even costlier!!!

 

As Harry Foster mentioned in his keynote at DVCon India 2015 – It’s about time to bring in the paradigm shift from “Increasing cycles of verification TO maximising verification per cycles”. He also quoted Henry Ford, the legend who founded Ford Motor Company and revolutionized transportation and American industry.

 

 

On that note, I wish you all a Happy Dussehra!!! Happy Holidays!!!


If you liked this post you would love -
Mythology & Verification
HANUMAN of verification team!
Trishool for verification
Verification and firecrackers

Trishool for verification

It’s the time of the year when I try to correlate Mythology with Verification. Yes, festive season is back in India and this is the time when we celebrate the fact that good prevails over evil. Given the diversity of Indian culture, there are a variety of mythological stories about demigods taking over evil. Well for us in the verification domain, it is the BUG that plays the evil preventing us from achieving first silicon success. While consumerism of electronic devices worked wonders in increasing the size of business, it actually forced the ASIC teams to gear up for developing better products in shrinking schedules. Given that verification is the long pole in achieving this goal, verification teams need a solution that ensures the functionality on chip is intact in a time bound fashion. The rising nature of design complexity has further transformed verification into a diverse problem where a single tool or methodology is unable to solve it. Clearly a multi pronged approach.... a TRISHOOL is required!

 

 

TRISHOOL is a Sanskrit word meaning 'three spears'. The symbol is polyvalent and is wielded by the Hindu God Shiva and Goddess Durga. Even the Greek God of sea – Poseidon and Neptune – the Roman God of the sea, are known to carry it. The three points have various meanings and significance. One of the common explanations being that Lord Shiva uses the Trishool to destroy the three worlds: the physical world, the world of culture drawn from the past and the world of the mind representing the processes of sensing and acting. In physical sense, the three spears would actually be fatal as compared to a single one. 

 

So basically we need a verification strategy equivalent to a Trishool to confirm that the efforts converge in rendering a fatal blow to the hidden bugs. The verification tools available today correlate well with the spears of Trishool and if put together would weed out bugs in a staged manner moving from IP to SoC verification. So which are the 3 main tools that should be part of this strategy to nail down the complex problem we are dealing with today?

 

Constrained RandomVerification (CRV) is the workhorse for IP verification & reuse of the efforts at SoC level makes it as the main spear or the central spear of the verification Trishool strategy. CRV is further complimented by the other two spears on either side i.e. Formal Verification and Graph based Verification. The focus of CRV is more at the IP level wherein the design is stressed under constraints to attack the thought through features (verification plan & coverage) and also hit corner cases or areas not comprehended. As we move from IP to SoC level, we face two major challenges. One is repetitive code typically combinational in nature where Formal techniques can prove the functionality comprehensively and in limited simulation cycles. Second is developing SoC level scenarios that cover all aspects of SoC and not just integration of IPs. The third spear or graph based verification comes to rescue at this level where multi processor integration, use cases, low power scenarios and performance simulations are enabled with much ease. 

 

Hope this festive season while we enjoy the food & sweets, the stories and enacts that we experience around will also given enough food for thought towards a Trishool strategy for verification.

 

Happy Dussehra!!!

 

Related posts -

HANUMAN of verification team!

Mythology & Verification

Over-verification : an intricate puzzle

For verification, it was an eventful week. DVCON 2013 kept everyone busy with record attendance at the sessions and by following the tweets & blogs that resulted from them. The major highlight of this year’s conference was release of the latest update to System Verilog standard, IEEE 1800-2012 and free PDF copies made available, courtesy - Accellera.

 

With verification constantly marching to increase its claim on ASIC design schedule while retaining its position as a major factor for silicon re-spins, verification planning was a hot topic of discussion at DVCON. Some of the interesting points that came out of a panel discussion on verification planning were –

 

- Verification plan is not just a wish list. You have to define how you’re going to get there.

- Problem is not over-planning, but over-verifying designs because there has not been enough planning.

- Biggest objection we hear is we don’t have time to capture a verification plan. But you'll lose more time if you don't.

- What’s useful in verification planning is “ruthless prioritization.” You can never get it all done.

- My biggest challenge is getting marketing input into my verification plan.

- Failure to plan means planning to fail.

 

Last week, I guest blogged on a similar topic based on a recent survey conducted by Catherine & Neil. Clearly, the issue of poor planning gets highlighted in all areas of product development.

 

Traditionally, the verification plans were just a list of features to be verified, addressing ‘what to verify’. With the emergence of CRV, the plans started including the second aspect i.e. ‘how to verify’. Further, to bring focus to this never ending verification problem, CDV was adopted. The verification plans now started including target numbers in terms of coverage (code, functional and assertions) to define ‘when are we done’. With a given set of resources, when the ASIC design schedule is imposed on the verification plan, meeting the goals is a challenge. There arises a need to prioritize verification in terms of the features. Remember, Any code that is not verified will not work!

 

To enable this “ruthless prioritization”, collaboration is required among marketing, software and hardware groups to align to the design objectives. Everyone needs to understand the potential end applications and preferential ways in the design to achieve them. In case of IPs, this could mean that the initial releases target a limited set of applications based on the customers on board. Once that is achieved, ‘over-verifying’ can take over to further close on the grey areas. In case of SoC, it is a tough call. While design cost continues to increase with diminishing dimensions, the break even may not happen with limited applications (as a result of limited verification) of the SoC. The problem gets aggravated further with the specifications changing on the fly. A platform based approach could be a potential solution where variants of SoC are churned out frequently, but again defining the platform and prioritizing the features boils down to the same problem. A tough nut to crack!

 

The whole point of over-verifying comes to the fore front because verification is the long pole in the schedule. What if the designs could be ‘over verified’ within the timelines? What does it take to achieve that? Are tools like intelligent test benches, formal verification, hardware acceleration or cloud computing a solution? If yes, what is the associated cost and how does it affect?

 

There is no easy answer to any of these questions. In words of Albert Einstein, “The world we have created is a product of our thinking. It cannot be changed without changing our thinking.”

 

Probably when an answer comes out, we will be on the road of commoditizing the hardware. Till then 'over-verification' is what we have to live with!

HANUMAN of verification team!

While Moore’s law continues to guide innovation and complexity in semiconductors, there are other factors that are further accelerating it. From iPod to iPhone5 via iPad, Apple has redefined the dynamics of this industry. New product launches include one from Apple every year, equally competitive and multiple products from other players and from Chinese cell phone makers every 3 months. There is an ever increasing demand of adding multiple functions to the SoCs while getting it right the 'first time' in 'limited time'. IP and sub system reuse has controlled the design lag of these SoCs significantly. While IP is assumed to be pre-verified at block level, the total time required to verify the SoC still is significant. A lot of this attributed to –

 

- Need for a staged approach to verify integration of the IPs on SoC

- Need to run concurrency tests, performance tests and use case scenarios

- Prolonged simulation time due to large design size

- Deploying multiple techniques to converge on verification closure

- Extended debug due to test bench complexity, test case complexity and all of the above

 

These challenges coupled with Murphy’s law conspire to pose a question on the verification schedule that claims a significant portion of the SoC design cycle. In the blog post Failure and Rescue, the author points to an interesting fact, “…things can and will go wrong. Yet some have a better capacity to prepare for the possibility, to limit the damage, and to sometimes even retrieve success from failure”. This directly applies to SoC verification too. Verification leads and managers are expected to build teams and ensure that the tools and processes deployed will diminish perceived risks while reduce unforeseen ones. The process involves bringing in engineers, tools and processes that match the project requirements. For effective management and resiliency, one needs HANUMAN to bring in balance to execution amidst uncertainty.

 

Who is Hanuman? HANUMAN is a Hindu deity, an ardent devotee of Lord Rama. With the commencement of festive season in India, number of mythological stories gain prominence. Hanuman is a central character in the Indian epic Ramayana, and also finds mentions in several other texts. He is also referred to as ‘Sankat Mochan’ i.e. SAVIOR who helped Lord Rama in precarious circumstances during the fight against evil. Last season, we correlated these epics with Verification here.

 

So where does HANUMAN find relevance in Verification?

 

SoCs today cannot be verified just with a team of verification engineers and a simulator. The process demands much more viz –

 

- Meticulous planning on what to verify, how to verify, who will verify what and when we are done.

- Architecting the verification infrastructure to address verification plan development & tracking, test scenario generation, VIP sourcing and integration, assertion identification, coverage collection, power aware simulations, acceleration or emulation, regression management and automated triaging.

- Engineers, who can use the infrastructure efficiently, are experts in protocols and methodology, strong with problem solving and debugging.

 

Handling complexity amidst dubiety demands a RESCUER i.e. HANUMAN. The stakes are high and so are the challenges. Multiple intricate situations arise during the course of verification to decelerate the schedule. The RECOVERER from such situations can be an engineer, a tool or a methodology and that entity at that instance is a manifestation of HANUMAN.

 

Sit and recall your past projects...

...if you delivered in such situations, feel proud to be one

...if you identify someone who did it, acknowledge one

...if you haven't till now then be one!

 

May these avatars of HANUMAN continue to drive your silicon ‘right the first time and every time’.

Happy Dussehra!

Communicating BUGS or BUGgy Communication

A few decades back when the designs had limited gate count, designers used to verify their code themselves. With design complexity increasing, the verification engineers were introduced to the ASIC teams. As Moore’s law continues to drive the complexity further, IP reuse picked up and this ensured that the engineers are spread all around the globe and communication across geographies is inevitable.

 

The reason for introducing the verification engineer was BUGS. A lot has been written and discussed on verification but reference to bugs is limited. With IPs getting sourced from different parts of the world and companies having extended teams everywhere, communicating the BUGs effectively becomes all the more important. “Wrong assumptions are costly” and in semiconductor industry this can throw a team out of business completely. Recently, in a mid-program verification audit for a startup with teams sitting between US & India, I realized that putting a well defined structure on communicating bugs could improve the turnaround time tremendously. Due to different time zones and working style, there was a lot of back & forth communication between the team members. Having a well defined format for communicating bugs helped a lot.

 

BUG COMMUNICATION CYCLE

 

BUG reported à BUG reproduced by designer à BUG fixed à FIX validated à BUG closed à revisit later for review, reproducing when required or data mining.

 

APPROACH

 

Before the advent of CRV, directed verification approach was common. Communicating bugs was simple and required limited information.  Introduction of CRV helped in the finding the bugs faster but sharing and preserving information around bugs became complicated. With a well defined approach, this problem can be moderated. Here is a sample format on what should be taken care of at each stage of the above cycle –

 

BUG reporting

 

Defining mnemonics for blocks or data path or scenarios etc. that can be appended along with the bug title helps. This enables categorizing the bugs at any time during project execution.

 

While the tool enforces adding the project related information, severity, prioritization and contact details of all concerned to broadcast information, the detailed description section should include –

 

- Brief description of the issue

- Information on diagnosis based on the debug

- Test case(s) used to discover this bug

- Seed value(s) for which the bug is surfaced

- Command line option to simulate the scenario and reproduce the issue

- Testbench Changelist/TAG on which the issue was diagnosed

- RTL Changelist/ TAG on which this issue was diagnosed

- Assertion/Cover point that covers this bug

- Link to available logs & dump that has the failure

 

BUG fixing

 

After the designer has root caused and fixed the bug, the bug report needs to be updated with –

 

- Root cause analysis and the fix

- Files affected during this fix

- RTL changelist/TAG that has the fix

 

FIX Validation

 

After the BUG moves to fixed stage, the verification engineer needs to update the TB if required and rerun the test. The test should pass with the seed value(s) required and then with multiple random seeds. The assertion/cover point should be covered in these runs multiple times. With this, the report can be updated further with –

 

- RTL changelist/TAG used to validate the bug

- Testbench changelist/TAG on which the issue was validated

- Pointer to the logs & waveforms of the validated test (if required to be preserved)

 

BUG Closed

 

After validating the fix, the bug can be moved to closed state. The verification engineer needs to check if there is a need to move this test to the smoke test list/mini regression and update the list accordingly.

 

Following the above approach would really help to communicate, reproduce and preserve the information around BUGs. The rising intricacies of the design demand a disciplined approach to attain efficiency in the outcome. Communicating bugs is the first step towards it!

 

HAPPY BUG HUNTING!!!

Mythology & Verification

It’s festive season in India! During this period one can experience the rich & diversified culture across the country. Apart from the fun and celebrations, this is the period when Indian mythological stories come across very frequently before everyone. While these stories convey subtle facts, rules and maxims to guide our daily lives, they also add meaning to these celebrations. All these stories related to Gods and demons are based on certain basic premises and are usually filled with some common concepts and ideas. It is considered that in every epoch as time passes the demons become prominent disturbing the regular functionality of the world. While these demons are on a rise, God himself arrives on this earth in different avatars (incarnations). He would master the art of war, build his arsenal with all sorts of weapons and finally start his quest to hunt all the demons and bring back the lost balance to this world.  

While pondering over these various stories a thought struck my mind. Isn’t this whole scheme the same in ASIC world? In every ASIC design, as the time passes and the RTL design gets ready, the bugs become prominent disturbing the regular functionality of the ASIC. While these bugs are on a rise, the verification engineer comes into picture in different roles (IP verification, SOC verification, Formal…). He would have mastered the art of verification and ready with his arsenal equipped with various techniques (constraint random verification, coverage, assertions, power aware verification, AMS, GLS…) to hunt down the bugs hiding in the design. At the end of this cycle he would restore the balance i.e. desired functionality of the ASIC and move on to the next one.

Verification surely has come a long way. I still remember the initial days of my career when every fresher (engg. graduate) wanted to be a designer and verification was considered to be a 2^nd option. However in the past decade the rising complexity of the designs have improved this role and placed it in the centre. During the recession (2009), my ASIC team had to face layoffs. Even during that period the verification engineers were able to manage more than 1 job offers in limited time.  The demand in verification is continuously on a rise. Now the verification engineer probably develops more lines of code (in comparison to RTL) to build a state of art test bench and uses multiple techniques to get the job done. The verification cycle directly affects both the schedule and quality (first Si success) of the product. The involvement has expanded to TLM modeling, Virtual platform development, functional verification, GLS, ATE vector generation and bring up keeping the engineer busy throughout the ASIC design process.   

So, to the members of the verification fraternity - while you are busy bringing balance to the ASIC functionality, enjoying the festive season and fascinated by the stories, make sure that your arsenal is always well equipped with the tricks and techniques in your pursuit towards Bug Hunting. As Albert Einstein rightly said –

“No amount of experimentation can ever prove me right; a single experiment can prove me wrong.”

Happy Dussehra! Happy Bug Hunting!

PS : This post is an experiment towards bridging technical and off topic subjects. Please provide your feedback by posting a comment or voting (Just 2 clicks).

PROOF of NO BUG... OR ...NO PROOF of BUG

To pursue a career in engineering, all of us have been through multiple courses in mathematics. All these courses involved proving equations or theorems. Given a relationship between variables we are asked to prove that relationship. There are defined methods and by following a step by step approach we are able to derive the desired proof. All this time we focus on proving LHS == RHS. Now imagine, if you are asked to prove the equivalence (LHS == RHS) by proving that there can be no way (LHS != RHS) the equation is non equivalent.

Sounds like a bully?

Interestingly, the whole practice of verifying semiconductor designs is based on this puzzling statement.

'Verification' i.e. sid'dha-karana, is a noun to the verb 'verify derived from Medieval Latin verificare : verus = true + facere = to make. So the literal meaning of the verification engineer's job is to make it true.

In an ideal world a fully verified design is the one where we have a PROOF of NO BUG (PNB) in the design. But the first learning imbibed in a verification engineer is that we cannot achieve 100% verification - an unconscious setback on the way one has been proving equality. A number of limitations (engineering or hardware resources, tools, schedule to name a few) that laid the foundation of this unachievable 100% verification has tossed the regular equation and shifted our focus from PNB to NPB  i.e. NO PROOF of BUG. The verification engineer thus endeavors to pursue all means to make sure there is no proof of a bug found (feels like a daunting task if you still relate it with proving there is no way that the equation is non equivalent). With a set of tools, methodologies, languages and checklists the hunt for the bugs i.e. all possible ways to prove the non equivalence begins. Slowly, as we approach closer to verification closure, the constantly passing regression and diminishing bug rate strengthens our assumption that no more bugs are concealed. With verification sign off, the design is labeled BUG FREE with the assumption that hopefully if no more bugs discovered, NPB == PNB. Silicon validation adds more credibility to our assumption, while the team lives with anxiety during the Si bring up. If we are fortunate enough to have customers who explored the design in the way we did in verification the assumption becomes immortal…. Happy ending!

Of course if we miss one of the way(s) of reaching to the bug(s), the result is much more costly in cash & kind when compared to our inability in proving an equation before our Maths teacher.

Maybe that’s the risk we as verification engineers assume when we pick NPB over PNB for whatever reasons.

Happy BUG hunting! :)