Hello FPGAmigos! Today, we embark on a journey to learn UVM(Universal Verification Methodology) easily. I am a complete novice in this area, so we’ll be learning together. I’d like to kick off this blog post series with a simple analogy I’ve discovered. At first glance, UVM might seem daunting and complex, but I’ve come to a realization: if you’ve ever played a video game, you’re already familiar with how UVM and verification work.

Have you been given the opportunity by your manager to tackle verification with UVM in your next mission, but you have no idea what it is? Are you a manager about to oversee a UVM project but find yourself clueless about its intricacies? Or perhaps you’re in HR, faced with the challenge of hiring a UVM wizard-engineer without understanding their role? Maybe you need to explain UVM to someone else. If any of these scenarios apply to you, this blog post is mad for you, assuming you have some experience with video games.

Through these analogies, I aim to provide you with a clearer understanding of verification and UVM, or at the very least, offer a concrete representation of them. Do you have a better metaphor or a game mechanics analogy? is there a notion missing ? I would be delighted to read your analogy in the comments !

The Verification Game

DUT : stands for Design Under Test. It is your FPGA that you want to test, what you code in VHDL, Verilog, Chisel etc.

The DUT is the Game, and you are the player. Your mission, should you choose to accept it : finish the game at 100% and report all the bug to the developper team.

What should I test ?

Have you played all the class in your game ? try every weapons ? finished the game with every playable characters ? HAVE YOU ROMANCE ALL NPCs ?!

Coverage : Is how thoroughly you have tested all the feature of you DUT.

There is several type of test, and how well you test that type is called coverage :

• Code Coverage – Exploring Every Area of the Game World: Just as code coverage involves executing every part of the design’s code, exploring every area in a game world ensures you’ve seen all possible locations, similar to ensuring every line, statement, branch, condition, path, and function in the code has been tested.
  • Line Coverage ~ Walking on every possible path.
  • Statement Coverage~ Interacting with every object.
  • Branch Coverage ~ Making every possible decision at decision points.
  • Condition Coverage ~ Experiencing every outcome of those decisions.
  • Path Coverage ~ Completing every possible questline or storyline.
  • Function Coverage ~ Using every game mechanic or system.
• Functional Coverage ~ Completing All Quests: Similar to testing all features and operational scenarios in a design, completing all quests ensures you’ve experienced all the game has to offer in terms of storylines, side missions, and objectives.
• Expression Coverage ~ Dialogue Choices Leading to All Possible Outcomes: Like evaluating different expressions in a design, making different dialogue choices to see all possible conversational outcomes tests the depth of the game’s narrative design.
• Toggle Coverage ~ Switching All Switchable Items On and Off: This could be likened to turning every switchable item or feature in a game on and off, such as lights, abilities, or even graphical settings, ensuring they all work in both states. Toggle coverage is checking every bit (or at least the meaningful ones) in the design has turned from 0 to 1 and 1 to 0.
• FSM (Finite State Machine) Coverage – Doing all the story branches: FSM Coverage in the context of a story-driven video game is akin to exploring every narrative branch and outcome. Each state represents a specific point in the story, and transitions are the choices a player makes that lead to another narrative state. Ensuring complete FSM coverage is like a player making every possible decision to experience all the story paths and endings. This approach guarantees that the player fully understands the narrative’s scope and the impact of their choices, mirroring the thorough testing of a digital system’s states and transitions.
• Assertion Coverage ~ Fulfilling All Game Achievements: Just as assertion coverage verifies the correctness of design assertions, completing all achievements or trophies verifies that specific actions or conditions have been successfully met in the game.

• Cross Coverage ~ Multi-Class or Combo Moves: This involves using combinations of different game elements or classes together, similar to analyzing the interaction between different parts of a design. For instance, combining spells or abilities to achieve unique effects. Mod 1 of IP1 works, Mod 2 of IP2 works, but do they work correctly together ?
• Path Coverage ~ Completing Every Branch of a Multi-Path Storyline: Ensuring you’ve experienced every branch and outcome of a game’s story, similar to testing all possible control flow paths in the code.

• Coverage of Corner Cases ~ Exploring Edge Cases in Game Mechanics: Like testing a design under extreme conditions, this could involve trying out unlikely or extreme actions in a game, such as attempting to escape the map boundaries or using items in unconventional ways to see if the game can handle these scenarios without breaking.

But how do you define the “100%” ? It’s usually more like any%. Where we could agree that finishing Baldur’s Gate 3 with every class is a relevant test, is finishing it with all different haircuts meaningful ? Same is for your DUT some verification do not worth the time and money.

Is it relevant to cover everything ? Depends on how much money your company allocate to testing, which usually depends on how much the legislation force your compagny to verify its design. Life at stack in a plane ? everything. A LED panel ? why do you even bother ? A LED panel in a plane ? hmmm…

What do tests find ? BUGs

The bugs encountered in video games are quite similar to those found in digital design. More precisely, video game bugs represent how software bugs manifest to users in the real world.

• Logical Errors – Game Logic Glitches: When the game behaves unexpectedly or incorrectly due to flawed logic, like an enemy not responding to being attacked or a puzzle solving itself incorrectly.
• Syntax Errors – Game Crashes on Startup: Similar to a game crashing because of a missing file or a syntax error in the game’s code, preventing it from running.
• Timing Errors – Synchronization Issues in Multiplayer Games: When actions or events are out of sync between players due to lags, akin to timing errors that cause data corruption or loss.
• Clock Domain Crossing (CDC) Bugs – Uncoordinated Multiplayer Characters: Imagine a multiplayer video game where characters controlled by different players are supposed to interact smoothly in a shared environment. However, due to lag or synchronization issues, one player’s actions are not updated timely on another player’s screen. This results in characters appearing to teleport or move erratically, rather than moving fluidly. Just as CDC bugs involve the improper transfer of data between different clock domains leading to potential data loss or corruption, uncoordinated character movements in a multiplayer game stem from failing to properly synchronize the actions across different players’ experiences.
• Race Conditions – Competing Game Mechanics: Imagine two game mechanics that interfere with each other under certain conditions, causing unpredictable outcomes, similar to race conditions in digital design.

• Reset Bugs – Corrupted Save Files: Just as corrupted save files can prevent a game from starting or resetting correctly, reset bugs in digital design lead to improper initialization.
• Arithmetic Bugs – Scoring or Health Calculation Errors: When a game incorrectly calculates scores, health, or other numeric values, akin to arithmetic errors in digital circuits.
• Memory Leaks and Buffer Overflows – Game Slowdowns or Crashes: Caused by inefficient memory use, these issues can slow down or crash a game, similar to memory management problems in digital systems.

• Deadlock – Game Freezes: When the game stops responding because it’s waiting for an event that never happens, mirroring a deadlock situation in digital design where processes wait indefinitely for resources.
• Simulation vs. Synthesis Mismatches – Differences Between Demo and Full Game: When features or performance seen in a game demo don’t match the final product, similar to discrepancies between a design’s simulated behavior and its post-synthesis operation.

Your tools to tests ? UVM Components

You’re set to embark on this testing journey, but there’s no room for fear, for you’re armed with your methodology: UVM and its array of components.

UVM : Universal Verification Methodology, is a standardized methodology used in the field of chip design for verifying digital designs and systems. It provides a framework for creating reusable verification environments in order to ensure design correctness before production.

Seated within your UVM environment, surrounded by all your Components/Equipment, you are ready to tackle the task :

• UVM Monitors: These components provide information about the DUT, akin to a computer screen that displays the game’s progress, along with console logs offering detailed feedback.
• UVM Drivers: How do you communicate with your DUT? Is it through Ethernet, SPI, UART? This is similar to choosing your gaming interface: keyboard and mouse, or a gamepad?
• UVM Items: These represent the data sent to your DUT for testing, much like the individual inputs a player makes during a game.
• UVM Sequences: Think of this as executing a combo move in a game, like a “HADOUKEN!”, the Konami code, or cheat codes in GTA 3 – a specific series of inputs.

• UVM Sequencer: A sequence of sequences – “HADOUKEN! HADOUKEN! HADOUKEN! HADOUKEN! HADOUKEN!” This is how you chain your techniques to outsmart your opponents. The strategy of the player.

• UVM Scoreboard: This compares expected outcomes with actual outcomes, similar to an arcade game’s scoreboard, a list of achievements, or the quest journal, tracking your progress and accomplishments.
• UVM Register: Models the registers within your DUT, similar to accessing RAM values for every variable, or tweaking game settings for optimal performance.
• UVM Agent: A container for other UVM components (drivers, sequencers, monitors), much like your controller. “Wait, didn’t you mention it was a driver?” Indeed, but it also monitors. The LED indicating you’re player 1 or 2, and the vibration feedback from hits, are informational inputs from the game, which are monitors. Similarly, a bot serves as an agent within the game.
• UVM Analysis Port: Broadcasts information to other subscribed components, akin to game mechanics that replicate information. When you communicate with a teammate, and a speaker icon appears on their screen, it’s because the information that you’re speaking is broadcast to those(your teammates) subscribed to receive it.

Conclusion

In conclusion, embarking on the journey of learning UVM can feel like stepping into a vast and complex game world, but just as with video games, familiarity and skill develop over time. Whether you’re diving into UVM for the first time or seeking to explain it to others, remember that like mastering a game, conquering UVM comes down to practice, patience, and a bit of strategic thinking. Let’s level up our verification skills together. Hope you have a better understanding now. See you for the next blog post.

If you like don’t forget to share, bookmark and comment !