Implementation of VMM Verification Method in AXI Bus System

Chip verification is becoming more and more like software rather than hardware work, which has gradually become a consensus in the industry. This article analyzes the verification platform of a system-on-chip ( SoC ) project of the Institute of Computing Technology of the Chinese Academy of Sciences from the perspective of software engineering. It also introduces the current popular verification method, that is, using a special verification language combined with a commercial verification model to quickly establish a test platform (Test-bench) and reuse it in future projects. The high-level verification language, methodology, verification basic library and simulation model mentioned in this article are gradually being widely adopted by the industry in recent years. The work of the Institute of Computing Technology is to use these latest achievements as a starting point to establish a test platform for SoC based on the AXI bus protocol. This new method can greatly improve the efficiency of chip verification, especially the initial investment of the project is greatly reduced. One of the reasons is the introduction of a large number of software engineering methods such as object-oriented programming. Of course, this also puts forward new requirements for the skills of verification engineers. Verification method In the field of verification, the obvious trend is language uniformity, unified simulation platform, more formal and efficient. Taking the project introduced in this article as an example, the language is SystemVerilog, the platform is built based on VMM, and the verification model (Verification IP) is used to greatly improve the efficiency. It is precisely because of the characteristics of component reusability, platform structure, coverage-oriented and high automation that verification work has become more formal and has a process to follow. Specialized verification languages ​​have been available for several years. They are derived from the verification system described by traditional pure Verilog (sometimes partially introduced into C/C++) and have developed greatly. Vera, e language and SystemVerilog, which has now become an IEEE standard, are the results of technological innovation during this period. The source of object-oriented programming characteristics is C++ language. As early as the era of pure Verilog language verification, there was a practice of using C++ to develop reusable verification code. Engineers valued the excellent features of OOP such as encapsulation, inheritance, polymorphism and reusability. If the verification language is not supported by the corresponding function library, the language itself will hardly be effective. To give a well-known example, in Windows programming, it is a more traditional practice to use C language to directly call the programming interface ( API ) of the Windows system, but few Windows programmers currently use it. Why? The workload is huge, and there is too much information to be maintained, from window size, menu list to program algorithm, all of which need to be considered. Therefore, Microsoft Basic Library (MFC), as one of the solutions, became popular. In contrast, C++, as the description language of Microsoft Basic Library, also became popular with the spread of the window system. Similar situations have also occurred in the field of modern chip verification. A large number of new methods, new models and new class libraries have emerged, which have reduced the burden of verification engineers to repeatedly develop underlying codes and put more energy into actual projects. The main components of this new idea are verification languages ​​(such as Vera, SystemVerilog), verification basic libraries (RVM, VMM) and corresponding verification models. Application of VMM VMM is not only a methodology, but also a specific implementation of the method. It includes a series of class libraries, class object connections and user-customized code. In the test platform shown in Figure 1, each component or object is an instantiation of the VMM basic class/extension class. The basic VMM classes involved are vmm_xactor, vmm_scenario_gen, and vmm_data.

Figure 1: Test platform block diagram.

To connect the components and form a whole, some other basic classes are needed, including vmm_env, vmm_channel, and vmm_xactor_callbacks. In addition, users need to add or modify constraints, interface connections, execution steps, coverage definitions, and automatic comparison mechanisms (auto-check) according to the actual situation of the chip.

1. Background

This type of verification platform makes full use of the achievements of software engineering, and divides the entire test platform into categories according to the functions implemented, so that each module can be developed and maintained separately. At present, the scale of chips tends to be large, and the protocols are becoming more complex. They usually need to transmit massive amounts of data and have a large number of ports. If the verification system is still established in the previous pure Verilog way, it will be difficult to meet the progress of chip development and wafer production. In short

, simply stimulating the DUT input port, monitoring the corresponding output port, and writing temporary code to compare data is a very backward verification method. Of course, we also see that some chips with simple structures still have a certain market, and the verification platform of pure Verilog language can also be very complex (but difficult to maintain), and the cost of learning object-oriented programming is easy to be daunting. However, these are individual cases outside the mainstream, so this article will not go into detail.

Although modern verification systems contain a large number of modules, various data types/protocols, and complex information transmission between modules (keeping synchronization, sharing data, etc.), they still inherit traditional methods, summarize previous verification experience, and establish test platforms according to conventional steps.

The VMM method is no exception. According to the usual process, it sets nine steps for all test platforms that apply VMM, which are defined in vmm_env: gen_cfg, build, reset_dut, cfg_dut, start, wait_for_end, stop, cleanup, and report.

On the other hand, the architecture of the VMM platform is divided according to the abstraction level and consists of the following components: test case, scenario generator, driver, monitor, scoreboard, data object, data transmission pipeline, callback function set, configuration set (dut_cfg and sys_cfg), coverage statistics component, and environment object that connects and integrates all the above components, as shown in Figure 2.

Figure 2: Using verification IP in a testbench can significantly reduce the workload.

For the use of each component in VMM, please refer to the manual jointly published by Synopsys and ARM.

2. Evaluation Criteria

The institute's previous verification work all used the high-level verification language Vera, and this is the first time to use SystemVerilog. To what extent can the introduction of the VMM method improve verification efficiency? This project is both a practical work and an evaluation.

We set the expected value based on the following considerations:

a. How long does it take to build a sample platform (including simple data transactions, self-testing, and coverage statistics)?

b. Scalability, that is, whether the constraints of random test vectors are changed, the automatic comparison mechanism is customized according to needs, the function coverage points are added, and the monitoring of the AXI protocol is complete.

c. Verification process controllability, such as inserting additional actions into the existing nine steps; controlling the order and number of execution of each step by changing the system configuration (such as resetting cfg_dut multiple times to achieve online repeated testing).

d. Ease of use should also be taken into account. After all, the VMM method covers a wide range of content, and it will take engineers a long time to fully master it. When we cannot know the reason, it is very important to know the reason quickly and start working.

The following description will focus on these aspects.

Integration of AXI-VIP

As mentioned above, the VMM method has the advantages of abstract hierarchical structure and nine execution steps, but it is only a general method. Whether it can meet the four criteria mentioned above is still a question. For example, the AXI master simulation model of the Institute of Computing Technology is written in Verilog and cannot be interconnected with the VMM platform in the short term; the complete AXI protocol detection is particularly important for the first chip system based on this bus; due to the rush of time, the AXI simulation model needs to be revised. These are problems that cannot be avoided in the project process, and the VMM method itself does not provide a solution.

1. Commercial Verification Model

The AXI Verification Model (VIP) is a commercial model of Synopsys. It is configurable, data transactions strictly comply with the AXI protocol, and have complete protocol checking functions. The most important point is that AXI-VIP provides an interface with the VMM platform. In fact, this VIP itself implements the functions of the driver component (Driver) and the monitor component (Monitor) of the VMM platform: the lower layer is connected to the DUT through a port, and the upper layer has a data transmission pipeline based on vmm_channel/vmm_xactor_callbacks. As shown in Figure 2, except for Test, Generator and Scoreboard, AXI-VIP has been implemented. The actual contribution of this commercial model to the development progress will depend on whether engineers can quickly get started. In other words, the ease of use of VIP determines its value.

In view of this, Synopsys provides a VMM example based on AXI-VIP. Among them, the DUT part is replaced by AXI Bus VIP, and the TB part implements the layered architecture shown in Figure 2. As a user, engineers only need to make the following modifications to obtain a verification platform with simple data transactions, self-testing, coverage statistics and other functions: replace the DUT and modify the interface signal name; rewrite the constraints of the test case test_1 to obtain their own test case; add configuration operations for the DUT. The above work was completed within one day, and the simulation output results include waveform files, log files and coverage reports.

2. Classes supported by AXI-VIP

The classes defined by AXI-VIP all have the same prefix name "dw_vip_axi", which constitute most of vmm_env:

a. dw_vip_axi_master_rvm;

b. dw_vip_axi_slave_rvm;

c. dw_vip_axi_monitor_rvm;

d. dw_vip_axi_master_transaction_scenario_gen;

e. dw_vip_axi_port_model_configuration;

f. dw_vip_axi_system_model_configuration;

g. dw_vip_axi_master_transaction_channel;

h. dw_vip_axi_slave_resp_transaction_channel;

i. dw_vip_axi_monitor_transaction_channel.

These classes will instantiate master device components, slave device components, monitoring components, configuration objects, data objects, data transmission pipelines, etc. They have their own variables and functions, providing rich control functions, covering all types of operations.

The completeness of functions does not damage the ease of use of AXI-VIP, which has been confirmed in the project. Through three days of training and practice, engineers were able to "modify constraints to randomly generate test vectors", rewrite the "automatic comparison mechanism" according to the chip test specifications, add "functional coverage points", and use the AXI monitoring component to "automatically check the protocol" and collect coverage related to the AXI protocol. Among them,

there is no ready-made VMM basic class available for rewriting the "automatic comparison mechanism" according to the chip test specifications. We started with a simple example provided by Synopsys, using the callback function set provided by AXI-VIP to obtain data transaction information and compare the outflow and inflow data in real time. Like other verification systems, this part of the work is the most diverse and the most core task, so it is expected that it takes up most of the three days.

Scoreboard implementation based on VMM

The verification team of our institute quickly established the automatic comparison mechanism of the test platform using the callback function set provided by AXI-VIP, guided by the VMM method. Although it cannot be finally applied to the whole system of more than a dozen master/slave devices, since this part of the code is encapsulated in the custom Scoreboard class, it is reusable and extensible, and meets the interface requirements of the VMM platform, it can be easily incorporated into future systems. The core SystemVerilog code of the Scoreboard class is provided by Synopsys, as shown in Figure 3.

Figure 3: Block diagram of the self-test unit.

The left end is the master device data buffer and comparison, the right end is the slave device data buffer and comparison, and the 1 to N and N to 1 conversions in the middle realize the distribution of data comparison tasks. The comparison codes of N slave devices are all extended from the same class. Because of this design, it is infinitely expandable. Based on the characteristics of only two master devices in this project, we have greatly simplified the structure on the left.

In addition to the core comparison part, the key task is to obtain the data stream of each master/slave device in real time. In AXI-VIP (including other VIPs of Synopsys), there are already ready-made functions available. Our engineers learned how to use it within two days and completed the development and debugging of the code in combination with actual practice.

AXI-VIP includes master devices, slave devices and monitoring devices, which will get a function callback opportunity at several key points of data transactions, as shown in Table 1.

Table 1: Correspondence table between callback functions and corresponding pipelines.

According to the data transaction phases corresponding to these callback functions, we select the post_input_channel_get of the master device and the pre_output_channel_put of the slave device to obtain transaction data.

Other functions can also be used to obtain data, such as the pre_activity_channel_put of the monitoring device, which can obtain input and output data. For details, please refer to the AXI-VIP user manual. In addition, the VMM callback function can also be used to control the verification process, insert error data, etc., which will not be expanded in this article due to space limitations.

Summary of this article

Because the trend of chip verification work requires more software knowledge and skills. This article takes the SoC project of the Institute of Computing Technology of the Chinese Academy of Sciences as an example to explain how to make full use of professional verification language basic libraries and commercial simulation models to quickly establish a test platform. The article details the use of each component and how the AXI-VIP object is incorporated into the VMM framework, as well as the practical significance of doing so.

The VMM method is based on the SystemVerilog language and provides a complete function library, while the supplementary AXI-VIP is fully functional and easy to use. Based on this new method, the verification group engineers of our institute quickly established a set of easily expandable test platforms within five working days. In the process of establishing the new system, a design loophole was discovered, which fully demonstrated the efficiency of this method.