top of page
Writer's pictureAdam Taylor

MicroZed Chronicles: RTL Design Verification Techniques

Updated: Sep 20, 2020

A large part of a programmable logic developer’s time is not spent implementing RTL, but verifying RTL functionality and behavior. A few weeks ago, a young engineer asked me about simulation and its role in the development process. I intend to create several blogs focusing on how we can use Vivado XSIM to verify our design. However, verification of RTL can be a wider task than just performing a simulation.

So, before we look in more detail at Vivado XSIM, let’s first understand the entire verification landscape and what we are trying to achieve.


The main purpose of verifying an RTL design is to ensure that the design complies with the requirement specification and any certification requirements if the application is high reliability or mission critical.


There are several techniques we can use to ensure that the functionality of the RTL achieves the necessary standards.


Simulation – Simulation is by far the most popular verification method and the one always taught at schools when we are learning our craft. However, while simulation is an extremely useful tool in our toolbox, it does require us to ask the right questions in our test bench to bring to light any issues. Simulation can be very advanced allowing us to include post-layout timing information for gate-level simulation. Advanced simulators can also provide the ability to report on the quality of the test bench in stimulating the unit under test by providing code coverage metrics. In addition to the XSIM in Vivado, there are a range of commercial third-party simulations including ModelSim, Riviera and open-course simulators such as Verilator and GHDL.

Structural Analysis – Structural analysis is used to analyze the structure of the RTL code. Unlike simulation, structural analysis does not require the right question to be asked. Instead, it uses parsers to ensure compliance with language reference manuals (e.g. Verific). In addition to the Language Reference Manual checking the tool analyses, the code structural patterns which may lead to issues like terminal states in state machines, mismatched assignments, reset and clocking structures. Modern structural analysis tools such as Blue Pearl are very advanced and enable pre implementation analysis of Clock Domain Crossing (CDC) structures. Structural analysis allows you to enter simulation, focusing on functional performance and not identifying issues which could have been found faster earlier.

Formal Methods – Formal methods mathematically prove your design functions as expected. The mathematical models used are varied but includes bounded model checkers and mathematical induction. When we work with formal methods, we do define valid and invalid states for use by the formal methods tool. One of the most popular formal methods tools is Yosys-SMTBMC created by Claire Wolf. If you want to know more about using formal methods in your design, I would highly recommend reading Dan Gisselquist’s ZipCPU blog which has excellent formal tutorials.

Timing – Of course, it is not just verification of the functionality which is required for a successful implementation. We also need to achieve timing performance. If we have followed coding rules and sensible design practices, it helps us achieve timing. Most timing analysis is performed using vendor tools and controlled via constraints.


Often these different elements of verification will be used in a complimentary manner. For example, structural analysis will be run before simulation and formal verification. Done correctly, verification takes considerable time compared to RTL verification. It is also not unusual for it to be carried out by an independent team or engineer.

To help accelerate the verification timescales, several frameworks exist which can be used to help verify functional performance. These include UVM which is SystemVerilog based and OSVVM and UVVM which are VHDL based. While the capabilities vary between framework, typically they offer interface models, constrained random support, and scoreboard / coverage.


Now that we know a little more about the verification landscape, we can take a closer look at the simulation capabilities in Vivado in future posts. I am also going to run through a few more complex test benches using a commercial third-party simulator utilizing one of the simulation frameworks above.


We'll get started with XSIM next!

0 comments

Comments


bottom of page