Fact1: Innovation need not be a new invention.

Even a short and a simple script or a piece of code that eases out your day-to-day activities or help
you save some time for yourself or for your team is an innovation.

One common trait I've seen across highly sought after DV engineers is their ability to automate
recurring tasks, and use the saved time (due to automation) to pick up other DV tasks and activities
that would otherwise usually get neglected or de-prioritized.

Time is of essence in Design Verification. The amount of time automation helps you save, could be
used to find other critical corner case bugs.

Automation is foundation for Design Verification. It doesn't matter which programming language
you use. Use the one you are most comfortable with (C/Perl/Shell/TCL/Python).

Sit down weekly once and analyze if you are spending time doing the same task iteratively day in
and day out. Why not automate it?

Fact2: Asking for help when required is never a bad idea!

It's quite normal to feel overwhelmed and exhausted. And sometimes juggling between multiple
assignments and managing tens of tasks in parallel looks petrifying.

In case it’s not easy to make a priority call or if all the tasks are critical, its best to seek help from
colleagues, seniors, and management; rather than feeling stressed out.

Eventually, teamwork makes a dream work!

Fact3: Design Verification is not a difficult skill to master for anyone willing to learn, as fault finding
comes naturally to individuals 🙂

Fact4: Generic rule of thumb:

(Number of DV engineers) >= 2* (Number of Design engineers)

Fact5: Assertion development has extremely high ROI.

For any project, assertion coding is extremely critical and rewarding due to multiple reasons:

1. Leads to better understanding of design as it requires knowledge of design.

2. Easiest to debug. EDA tools tell exactly which assertion is failing.
3. Reuse in Formal verification
4. Ability to port across multiple levels (IP, SS, SoC, Emulation, GLS) if coded properly.
5. Flexibility to add coverage on SVA.

Fact6: UPF Power Aware Simulations are a must run for any project having multiple power and
voltage domains.

Extremely risky if this is missed out!

Fact7: Coverage closure is consequential!

For every bug escape from IP to SS to SoC to Silicon, there exists a coverage hole (either code or
functional).

Hence, closing relevant coverage matrix at each level is critical and assigning sufficient resources for
coverage closure is of paramount importance for a project.

Fact8: Debug Insane or remain the same.

Perfection is obtained through practice. More failures you debug, more you learn.

Fact9: Documenting regression/test failures is critical.

Test failure is quite common in Design Verification. Whether you're writing a new test, running legacy
test on a new design, creating any new TB collateral (checker, tracker, assertion, sequence, etc.),
adding new run/compile time options, or just moving from one tool version to another, etc. - test
failures could occur.

While it's crucial to root cause all such failures, it's equally important to document all different failure
buckets. This is primarily because:

1. Email threads are difficult to track,

2. Some failures are seed specific and in case the failures are not debugged properly, the same test
may pass in next iteration with a different seed (leading to bug miss),
3. It’s easier to share a Bug ID with team members (in case they are seeing similar issue at same time
or later in the future) rather than looking for emails,
4. Once a bug is filed and is open, it can't go un-noticed during project closure sprints.

In case the issue root cause is taking time, you could start by filing a bug on yourself and then
disposition it later to a correct owner once the issue is root caused. After all, main aim of DV is to
find all observable bugs in the design!

Fact10: Running Regressions is NOT a frivolous, insignificant, or minuscule task.

Running regressions at a pre-defined and an agreed upon frequency is one of the most important
DV task. It not only helps with coverage closure, but also help find random seed corner case
scenarios.

Fact11: Assumptions are lethal for DV

Design Verification should be done based upon the Microarchitectural/Design Specifications and not
based upon any assumptions.

Fact12: Connectivity verification is essential as we move from IP to Subsystems to SoC level

verification.

Even though it is easy to enable (low hanging fruit) and perform connectivity checks, its mostly
ignored - thereby leading to reliance on costly dynamic simulations to unearth connectivity issues.

Fact13: Trivia: For every regression started on a Friday afternoon, there are new and unique failures
that take up weekend to be debugged and fixed 🙂.

More often than not, these are random environment failures.

Fact14: Design/DV engineers become good lawyers too.

They necessarily go through Bug Boards/Courts for every bug found after RTL freeze 🙂

Fact15: Disk space management is critical.

If disk space is not managed/utilized properly, it could result in mismanagement of project timelines.

Many a times, regression runs, as well as test runs with waveform dumps are killed due to less disk
space.

Fact16: Best way to learn UVM and be able to admire its advantages is to learn by practice.

Just convert a SystemVerilog based testbench to a UVM one and you will learn UVM.

Fact17: Discussions and Debates are good!

Discussions and Debates (if done with correct mindset) are good for a quality DV. While discussions
could help figure out missing pieces and scenarios, debates could help explore better ways of doing
things and understand pros/cons in a detailed manner.

Fact18: Choosing correct EDA tools is quintessential for timely closure of DV activities with high
confidence and quality.

Fact19: Keep Calm and debug GLS!

Fact20: Formal Verification is Magic!

While simulation is still the major component of any hardware verification project lifecycle,
importance of Formal Verification is growing, and overtime it has become a significant part of the
overall design process. A dynamic simulation can only increase the confidence regarding the design
correctness, and it can never be 100% complete. However, formal verification has the ability to
comprehensively prove correctness of a design against a specification. The complexity though is in
the size of the design and hence appropriate areas/features are normally selected for formal
verification.