There are three approaches related to functional verification: black-box, white-box, and gray-box.
In the black-box approach, there is no knowledge of the design implementation. All verification is accomplished through the device interfaces, stimulating the inputs and monitoring the outputs. This approach has the advantage of independent verification from design implementation, although sometimes it is difficult to determine the source of problems. For that reason, a pure black-box approach is impractical for large designs today.
Conversely, the white-box approach has full visibility of the internal structure and design implementation, allowing the detection of internal functional problems. However, this approach requires detailed knowledge of the design implementation, and changes in the device may require changes in the test bench.
Gray-box verification is a compromise between the previous two. A gray-box approach controls and observes a design entirely through its top-level interfaces (like a black-box), but it includes some non-functional modifications to provide additional visibility and controllability.
In this work, a gray-box method is proposed to know the value of internal signals to the DUT. A new class called logic analyzer is created and connected to the DUT using the same approach as the agents. The link between the RTL design and verification components is the top module, where the DUT interface (I/O ports) connects to the virtual interfaces of the agents and, in this case, the logic analyzer.
The logic analyzer is composed of one configuration class that holds the component interface.
The configuration class allows the connection between the DUT internal signal and the logic analyzer component through the uvm factory. On the other hand, the virtual interface has methods to monitor the signal connected to it.
The following picture shows the logic analyzer configure class. It can be seen that it is a parameterized class to adapt to any internal signal size.
The logic analyzer interface has two methods to determine signal value. A task, called wait_edge, waits until the internal signal value matches the value passed through the task argument, and a function that returns the signal value at the moment it is executed.
The functionality of the logic analyzer can be understood with the following example. Considering the DUT structure, it is mandatory to monitor the b1_signal value. The b1_signal is inside the block_1 instance. The full path is DUT.block1_inst.b1_signal
The first step is to connect the logic analyzer interface to the signal using the bind method. It needs the full path signal.
Then, the interface must be registered on the uvm factory. It is important to note that after the bind method, the logic analyzer instance becomes local to the DUT [2]. The sentence is shown in the next picture.
Finally, the logic analyzer instance is created in the environment. The configuration class links the interface registered on the factory with the logic analyzer instance.
The methods are executed on the virtual sequences. The sentence seen in the next picture waits until the b1_signal matches with the value of 1 (when a rising_edge happens).
Advantages:
- In some scenarios, when the test must wait until a signal reaches some value, this approach is more accurate than time delays.
- It can detect design problems that do not reflect just monitoring interface signals.
Drawbacks:
- The general verification approach is black-box. The verification team should focus on DUT functionality and avoid design particularities.
- The signal path bound to the logic analyzer instance is dependent on the RTL design. This can produce scalability problems. It can be partially resolved with `define sentences.
[1] J. Bergeron, Writing Testbenches using System Verilog. Boston, MA: Springer US, 2006. doi: 10.1007/0-387-31275-7.[1] J. Bergeron, Writing Testbenches using System Verilog. Boston, MA: Springer US, 2006. doi: 10.1007/0-387-31275-7.
[2] «Bind interface UVM / Systemverilog - SystemVerilog», Verification Academy. Accedido: 6 de noviembre de 2024. [En línea]. Disponible en: https://verificationacademy.com/forums/t/bind-interface-uvm-systemverilog/32285
Design Verification Engineer at Emtech S.A.
Thanks, Marcelo Pouso for their valuable feedback and insightful reviews.
Any Comments or questions, please feel free to contact us: info@emtech.com.ar