阅读说明：本技术 面向amba总线架构芯片的性能验证系统及应用 (Performance verification system for AMBA bus architecture chip and application ) 是由 蔡浩 袁力 胡扬央 于 2021-08-13 设计创作，主要内容包括：本发明公开了面向AMBA总线架构芯片的性能验证系统及应用,涉及芯片开发技术领域。所述系统中,在待测SoC端利用AMBA的VIP组件搭建UVM验证平台,UVM验证平台被配置为：获取约束文件,根据约束文件产生随机读写传输包,将生成的读写传输包发送至前述IP模块的主VIP后,通过该主VIP模拟总线行为并监测AMBA总线上的传输数据；在监测过程中,通过总线监控器模块监测总线上的IP模块的数据带宽信息后,将获取的数据带宽信息与总带宽进行比对以判断是否符合需求。本发明能够实现芯片性能特性的预评估,可以尽早实现芯片性能特性的收敛工作,降低了迭代风险,缩短了芯片研发周期,同时降低了系统风险。(The invention discloses a performance verification system for an AMBA bus architecture chip and application thereof, and relates to the technical field of chip development. In the system, a UVM verification platform is built by utilizing a VIP component of AMBA at an SoC terminal to be tested, and the UVM verification platform is configured to: acquiring a constraint file, generating a random read-write transmission packet according to the constraint file, sending the generated read-write transmission packet to a main VIP of the IP module, simulating bus behavior through the main VIP and monitoring transmission data on an AMBA bus; in the monitoring process, after the data bandwidth information of the IP module on the bus is monitored by the bus monitor module, the acquired data bandwidth information is compared with the total bandwidth to judge whether the data bandwidth information meets the requirement or not. The invention can realize the pre-evaluation of the performance characteristics of the chip, can realize the convergence work of the performance characteristics of the chip as early as possible, reduces the iteration risk, shortens the research and development period of the chip and simultaneously reduces the system risk.)

1. The utility model provides a performance verification system towards AMBA bus architecture chip, includes UVM verification platform and the SoC that awaits measuring, its characterized in that:

an AMBA bus is adopted in the SoC to be tested as a bus framework of on-chip communication, an IP module is integrated in the SoC to be tested, and the UVM verification platform is built at the SoC end to be tested by utilizing a VIP component of the AMBA;

the UVM verification platform is configured to: acquiring a constraint file, wherein the constraint file is used for configuring read-write operation parameter information of bus interface data of the IP module; generating a random read-write transmission packet according to the constraint file, sending the generated read-write transmission packet to a main VIP of the IP module, simulating bus behavior through the main VIP and monitoring transmission data on an AMBA bus; in the monitoring process, after the data bandwidth information of the IP module on the AMBA bus is monitored through the bus monitor module, the acquired data bandwidth information is compared with the total bandwidth of the AMBA bus so as to judge whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted.

2. The system of claim 1, wherein: the step of judging whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted comprises the following steps:

acquiring data bandwidth values of all IP modules on the AMBA bus, and performing sum operation on the data bandwidth of each IP module to obtain a simulated bandwidth sum B_sum；

Comparing the analog bandwidth sum B_sumTotal bandwidth B with the AMBA bus_enThe size of (d); when the sum of analog bandwidths is B_sumLess than or equal to total bandwidth B_enJudging that the design of the IP module meets the requirements without adjusting the design parameters of the IP module or the bus architecture of the SoC to be tested; when the sum of analog bandwidths is B_sumGreater than the total bandwidth B_enAnd judging that the design of the IP module does not meet the requirement, and adjusting the design parameters of the IP module or adjusting the bus architecture of the SoC to be tested.

3. The system according to claim 1 or 2, characterized in that: a constraint file generation unit is arranged corresponding to the SoC to be tested, and the constraint file generation unit is configured to: after the data stream characteristics of the IP module are obtained, corresponding read-write operation parameter information is stored in a template file with a general format, and the template file is subjected to constraint compiling script to generate the constraint file;

the data stream characteristics comprise IP module names, bus interface types and read-write operation parameters of bus interface data; the read-write operation parameters comprise data, addresses, read-write types, read-write ratios, burst lengths in read-write operations and proportion information.

4. The system of claim 3, wherein: the template file is an excel file, and the constraint compiling script is a python script;

the bus interface types comprise an AMBA AXI bus, an AMBA AHB bus and an AMBA APB bus, and for the IP modules mounted on the AMBA AXI bus, the AMBA AHB bus and the AMBA APB bus, corresponding AMBA AXI bus driver, AMBA AHB bus driver and AMBA APB bus driver are respectively arranged on the UVM verification platform.

5. The system of claim 4, wherein: the burst length ranges from 1 to 16; the preset fields of the table of the excel file at least comprise a module name field, a read/write type field and a duty ratio field of each burst length.

6. The system of claim 3, wherein: an IP module setting unit and an SoC bus architecture setting unit are arranged corresponding to the SoC to be tested, the IP module setting unit is used for collecting design parameter information of an IP module, and the SoC bus architecture setting unit is used for collecting design parameter information of a system bus architecture of the SoC;

the constraint file generating unit is connected with an IP module setting unit, and the IP module setting unit is configured to: when the design parameter information of the IP module is adjusted by a user, the adjusted design parameter information of the IP module is acquired and sent to a constraint file generating unit;

the constraint file generation unit can generate a new constraint file after receiving the design parameter information of the adjusted IP module and send the new constraint file to the UVM verification platform to verify the design of the adjusted IP module;

the SoC bus architecture setting unit is connected with the UVM verification platform and is configured to: when the design parameter information of the system bus architecture is adjusted by a user, the adjusted design parameter information of the system bus architecture is acquired and sent to a UVM (universal video multicast) verification platform;

and after receiving the adjusted design parameter information of the system bus architecture, the UVM verification platform can update the parameter information of the bus architecture and trigger verification.

7. The system of claim 1, wherein: the UVM verification platform comprises a VIP verification mode and an RTL verification mode, and the modes are switched according to a mode switching instruction of a user or a system.

8. A performance verification method for an AMBA bus architecture chip is characterized by comprising the following steps:

building a UVM verification platform by using a VIP component of AMBA at a SoC end to be tested, wherein an AMBA bus is adopted in the SoC to be tested as a bus framework of on-chip communication, and an IP module is integrated in the SoC to be tested;

acquiring design parameter information of the IP module, generating a constraint file, and sending the constraint file to the UVM verification platform; the constraint file is used for configuring read-write operation parameter information of the bus interface data of the IP module;

according to the constraint file, the UVM verification platform generates a random read-write transmission packet, and after the generated read-write transmission packet is sent to the main VIP of the IP module, the bus behavior is simulated through the main VIP and transmission data on the AMBA bus are monitored;

in the monitoring process, after the data bandwidth information of the IP module on the AMBA bus is acquired through the bus monitor module, the acquired data bandwidth information is compared with the total bandwidth of the AMBA bus to judge whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted.

9. The method of claim 8, wherein: the step of determining whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted includes,

acquiring data bandwidth values of all IP modules on the AMBA bus, and performing sum operation on the data bandwidth of each IP module to obtain a simulated bandwidth sum B_sum；

Comparing the analog bandwidth sum B_sumTotal bandwidth B with the AMBA bus_enThe size of (d); when the sum of analog bandwidths is B_sumLess than or equal to total bandwidth B_enJudging that the design of the IP module meets the requirements without adjusting the design parameters of the IP module or the bus architecture of the SoC to be tested; when the sum of analog bandwidths is B_sumGreater than the total bandwidth B_enAnd judging that the design of the IP module does not meet the requirement, and adjusting the design parameters of the IP module or adjusting the bus architecture of the SoC to be tested.

10. The method of claim 8, wherein: the method comprises the following steps of dividing the data stream characteristic requirements of an IP module according to a chip application scene before building a UVM verification platform;

the method comprises the steps that for an IP module with historical simulation data, after data flow characteristic information provided by the historical simulation data is obtained, the data flow characteristic information is compared with a preset data flow characteristic requirement, and when the data flow characteristic information and the preset data flow characteristic requirement are judged to be in accordance, the bus port data flow characteristic of the IP module is obtained from the historical simulation data; for the IP module without historical simulation data, collecting the data flow characteristic requirement formulated by a user, and acquiring the bus port data flow characteristic of the IP module according to the requirement.

Technical Field

The invention relates to the technical field of chip development, in particular to a performance verification system for an AMBA bus architecture chip and application thereof.

Background

In the field of IC (integrated circuit) design, the mainstream Chip design is more and more designed to be SoC (System-on-Chip) design using reusable IP (or IP core, which is a specific functional module in the Chip). In the SOC design based on IP multiplexing, on-chip bus design is the most critical issue. Among them, an Advanced Microcontroller Bus Architecture (AMBA) on-chip Bus proposed by ARM corporation is favored by IP developers and system integrators of SOC, and has become a popular industry standard on-chip structure. The AMBA specification mainly includes an ahb (advanced High performance bus) system bus, an apb (advanced Peripheral bus) Peripheral bus, and an axi (advanced eXtensible interface) bus.

In the design and development process of the AMBA bus architecture chip, chip performance verification is required to evaluate whether the performance characteristics of the chip meet design requirements, so as to ensure the speed and quality of the chip. With the increase of chip scale, more and more IP modules are integrated in the chip, and the chip performance verification work is very important, which is one of the determining factors for determining whether the chip can meet the actual requirements. Existing VIP (Verification IP) modules can provide various on-chip and off-chip functional models, including pcie (peripheral Component Interconnect express), usb (universal Serial bus), and ethernet models. By way of example, a VIP module, such as AMBA AXI3 and AXI4, may use the functional model in the VIP module described above to test the SoC interface before streaming, thereby verifying that an interface meets published standards.

On the other hand, Verification by Universal Verification Methodology (UVM) is a mainstream Verification method, which provides a reusable and hierarchical Verification platform framework, has the characteristics of clear hierarchy, flexibility, easy use, extensibility, and the like, and has become a standard for chip industry Verification at present. In the prior art, various UVM verification platforms (or called UVM verification environments) built based on UVM verification methodologies are also provided, and the performance of an IP module in a chip to be tested is verified through the UVM verification platforms. An automatic generation device of a module-level UVM verification platform based on an AMBA bus, such as that disclosed in Chinese patent ZL 201310589511.7; for example, the verification platform development method based on the UVM disclosed in chinese patent application CN 202010537036.9.

However, in the conventional chip design and development process, after the development of each IP module is completed, each IP module is integrated into the SoC system for simulation, and then performance verification is performed; if the performance characteristics do not meet the requirements (namely the performance indexes do not meet the design requirements), the method is modified, and then simulation and performance verification are carried out on the modified design. The above scheme has the following defects: on one hand, the iteration time is increased and the chip design cycle is prolonged due to repeated modification and verification; on the other hand, since the chip performance verification is performed at the later stage of the chip design development process (after the chip simulation is completed), the performance characteristics of the chip before the performance verification are in an uncontrollable state (the performance characteristics cannot be known), and the system risk is increased.

In summary, how to implement the convergence work of the performance characteristics of the chip as early as possible to shorten the chip development cycle and reduce the system risk is a technical problem that needs to be solved at present.

Disclosure of Invention

The invention aims to: the defects of the prior art are overcome, and the performance verification system and the application thereof facing the AMBA bus architecture chip are provided. According to the invention, based on the data flow characteristic requirements of the IP module, constraint randomization simulation is carried out on a transmission packet (transaction) to carry out simulation on the behavior of the IP bus, so that whether the performance characteristics of the chip meet the design requirements or not is evaluated, pre-evaluation of the performance characteristics of the chip can be realized, designers can modify the performance characteristics of the chip based on the pre-evaluation result to realize convergence work of the performance characteristics of the chip as early as possible, the iteration risk is reduced, the research and development period of the chip is shortened, and the system risk is reduced.

In order to achieve the above object, the present invention provides the following technical solutions:

a performance verification system for an AMBA bus architecture chip comprises a UVM verification platform and an SoC to be tested;

an AMBA bus is adopted in the SoC to be tested as a bus framework of on-chip communication, an IP module is integrated in the SoC to be tested, and the UVM verification platform is built at the SoC end to be tested by utilizing a VIP component of the AMBA;

the UVM verification platform is configured to: acquiring a constraint file, wherein the constraint file is used for configuring read-write operation parameter information of bus interface data of the IP module; generating a random read-write transmission packet according to the constraint file, sending the generated read-write transmission packet to a main VIP of the IP module, simulating bus behavior through the main VIP and monitoring transmission data on an AMBA bus; in the monitoring process, after the data bandwidth information of the IP module on the AMBA bus is monitored through the bus monitor module, the acquired data bandwidth information is compared with the total bandwidth of the AMBA bus so as to judge whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted.

Further, the step of judging whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted is:

acquiring data bandwidth values of all IP modules on an AMBA bus, and carrying out sum operation on the data bandwidth of each IP module to obtain a simulation bandwidth sum Bsum;

comparing the analog bandwidth sum Bsum with the total bandwidth Ben of the AMBA bus; when the total bandwidth Bsum is less than or equal to the total bandwidth Ben, judging that the design of the IP module meets the requirement without adjusting the design parameters of the IP module or the bus architecture of the SoC to be tested; when the total bandwidth Bsum of the simulation is greater than the total bandwidth Ben, it is determined that the design of the IP module does not meet the requirement, and the design parameters of the IP module or the bus architecture of the SoC to be tested need to be adjusted.

Further, a constraint file generation unit is arranged corresponding to the SoC to be tested, and the constraint file generation unit is configured to: after the data stream characteristics of the IP module are obtained, corresponding read-write operation parameter information is stored in a template file with a general format, and the template file is subjected to constraint compiling script to generate the constraint file;

the data stream characteristics comprise IP module names, bus interface types and read-write operation parameters of bus interface data; the read-write operation parameters comprise data, addresses, read-write types, read-write ratios, burst lengths in read-write operations and proportion information.

Further, the template file is an excel file, and the constraint compiling script is a python script;

the bus interface types comprise an AMBA AXI bus, an AMBA AHB bus and an AMBA APB bus, and for the IP modules mounted on the AMBA AXI bus, the AMBA AHB bus and the AMBA APB bus, corresponding AMBA AXI bus driver, AMBA AHB bus driver and AMBA APB bus driver are respectively arranged on the UVM verification platform.

Further, the burst length ranges from 1 to 16; the preset fields of the table of the excel file at least comprise a module name field, a read/write type field and a duty ratio field of each burst length.

Further, an IP module setting unit and an SoC bus architecture setting unit are arranged corresponding to the SoC to be tested, the IP module setting unit is used for collecting design parameter information of an IP module, and the SoC bus architecture setting unit is used for collecting design parameter information of a system bus architecture of the SoC;

the constraint file generating unit is connected with an IP module setting unit, and the IP module setting unit is configured to: when the design parameter information of the IP module is adjusted by a user, the adjusted design parameter information of the IP module is acquired and sent to a constraint file generating unit;

the constraint file generation unit can generate a new constraint file after receiving the design parameter information of the adjusted IP module and send the new constraint file to the UVM verification platform to verify the design of the adjusted IP module;

the SoC bus architecture setting unit is connected with the UVM verification platform and is configured to: when the design parameter information of the system bus architecture is adjusted by a user, the adjusted design parameter information of the system bus architecture is acquired and sent to a UVM (universal video multicast) verification platform;

and after receiving the adjusted design parameter information of the system bus architecture, the UVM verification platform can update the parameter information of the bus architecture and trigger verification.

Further, the UVM verification platform comprises a VIP verification mode and an RTL verification mode, and mode switching is carried out according to a mode switching instruction of a user or a system.

The invention also provides a performance verification method for the AMBA bus architecture chip, which comprises the following steps:

building a UVM verification platform by using a VIP component of AMBA at a SoC end to be tested, wherein an AMBA bus is adopted in the SoC to be tested as a bus framework of on-chip communication, and an IP module is integrated in the SoC to be tested;

acquiring design parameter information of the IP module, generating a constraint file, and sending the constraint file to the UVM verification platform; the constraint file is used for configuring read-write operation parameter information of the bus interface data of the IP module;

according to the constraint file, the UVM verification platform generates a random read-write transmission packet, and after the generated read-write transmission packet is sent to the main VIP of the IP module, the bus behavior is simulated through the main VIP and transmission data on the AMBA bus are monitored;

in the monitoring process, after the data bandwidth information of the IP module on the AMBA bus is acquired through the bus monitor module, the acquired data bandwidth information is compared with the total bandwidth of the AMBA bus to judge whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted.

Further, the step of determining whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted includes,

acquiring data bandwidth values of all IP modules on an AMBA bus, and carrying out sum operation on the data bandwidth of each IP module to obtain a simulation bandwidth sum Bsum;

comparing the analog bandwidth sum Bsum with the total bandwidth Ben of the AMBA bus; when the total bandwidth Bsum is less than or equal to the total bandwidth Ben, judging that the design of the IP module meets the requirement without adjusting the design parameters of the IP module or the bus architecture of the SoC to be tested; when the total bandwidth Bsum of the simulation is greater than the total bandwidth Ben, it is determined that the design of the IP module does not meet the requirement, and the design parameters of the IP module or the bus architecture of the SoC to be tested need to be adjusted.

Further, before the UVM verification platform is built, the method also comprises the step of dividing the data stream characteristic requirements of the IP module according to the chip application scene;

the method comprises the steps that for an IP module with historical simulation data, after data flow characteristic information provided by the historical simulation data is obtained, the data flow characteristic information is compared with a preset data flow characteristic requirement, and when the data flow characteristic information and the preset data flow characteristic requirement are judged to be in accordance, the bus port data flow characteristic of the IP module is obtained from the historical simulation data; for the IP module without historical simulation data, collecting the data flow characteristic requirement formulated by a user, and acquiring the bus port data flow characteristic of the IP module according to the requirement.

Due to the adoption of the technical scheme, compared with the prior art, the invention has the following advantages and positive effects as examples: based on the data flow characteristic requirement of the IP module, constraint randomization simulation is carried out on a transmission packet (transaction) to carry out analog simulation on the behavior of the IP bus, so that whether the performance characteristic of the chip meets the design requirement or not is evaluated, pre-evaluation of the performance characteristic of the chip can be realized, designers can modify the performance characteristic of the chip based on the pre-evaluation result to realize convergence work of the performance characteristic of the chip as early as possible, the iteration risk is reduced, the research and development period of the chip is shortened, and the system risk is reduced.

Drawings

Fig. 1 is a schematic output transmission diagram of a performance verification system according to an embodiment of the present invention.

Fig. 2 is a schematic view of a verification process of the UVM verification platform according to an embodiment of the present invention.

Fig. 3 is a schematic diagram of a data structure of an excel table according to an embodiment of the present invention.

Detailed Description

The performance verification system and application of the AMBA bus architecture-oriented chip disclosed by the invention are further described in detail with reference to the accompanying drawings and specific embodiments. It should be noted that technical features or combinations of technical features described in the following embodiments should not be considered as being isolated, and they may be combined with each other to achieve better technical effects. In the drawings of the embodiments described below, the same reference numerals appearing in the respective drawings denote the same features or components, and may be applied to different embodiments. Thus, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

It should be noted that the structures, proportions, sizes, and other dimensions shown in the drawings and described in the specification are only for the purpose of understanding and reading the present disclosure, and are not intended to limit the scope of the invention, which is defined by the claims, and any modifications of the structures, changes in the proportions and adjustments of the sizes and other dimensions, should be construed as falling within the scope of the invention unless the function and objectives of the invention are affected. The scope of the preferred embodiments of the present invention includes additional implementations in which functions may be executed out of order from that described or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the embodiments of the present invention.

Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate. In all examples shown and discussed herein, any particular value should be construed as merely illustrative, and not limiting. Thus, other examples of the exemplary embodiments may have different values.

Examples

The invention provides a performance verification system for an AMBA bus architecture chip. The system comprises a UVM verification platform and the SoC to be tested.

The internal of the SoC to be tested adopts an AMBA bus as a bus framework of on-chip communication, an IP module is integrated in the SoC to be tested, and the UVM verification platform is built at the SoC end to be tested by utilizing a VIP component of the AMBA.

As an example of a typical manner, an AMBA bus type of SoC based on an AMBA bus may include an ahb (advanced High performance bus) system bus, an apb (advanced Peripheral bus) Peripheral bus, and an axi (advanced eXtensible interface) bus. All modules in the SoC are logic modules on the SoC, and when the system is specifically set, an AMBA AXI bus can be selected as a primary bus for connecting a processor and a peripheral, an AMBA AHB bus can be selected as an on-chip local bus, and an AMBA APB bus can be selected to be connected with low-speed equipment. In this embodiment, for the IP modules mounted on the AMBA AXI bus, the AMBA AHB bus, and the AMBA APB bus, the UVM verification platform may be provided with the corresponding AMBA AXI bus driver, AMBA AHB bus driver, and AMBA APB bus driver, respectively.

The VIP component of the AMBA verifies the design according to the details of the protocol specification. The system can generate comprehensive test excitation, verify different interfaces and standard bus protocols, shorten SoC verification and increase test coverage. In particular, the VIP may include test cases (test cases), drivers, configuration components, interface-specific test plans, test components that connect to DUTs in a test bed to simulate or verify IP or SoC designs, and the like. The test case (test case) is implemented by means of a system verilog program. The VIP components of the AMBA bus may include an AMBA Master VIP (i.e., Master VIP) and an AMBA Slave VIP (i.e., Slave VIP), as shown in fig. 1, which exemplify VIP components including AMBA Master VIP0, AMBA Master VIP1, … …, AMBA Master VIPn, and AMBA Slave VIP0, AMBA Slave VIP1, … …, and AMBA Slave VIPn, where n is an integer greater than or equal to 1.

The UVM verification platform is configured to: acquiring a constraint file, wherein the constraint file is used for configuring read-write operation parameter information of bus interface data of the IP module; generating a random read-write transmission packet according to the constraint file, sending the generated read-write transmission packet to a main VIP (Master VIP) of the IP module, and then simulating an AMBA bus behavior and monitoring transmission data on the AMBA bus by the main VIP, as shown in fig. 1.

In the monitoring process, after the data bandwidth information of the IP module on the AMBA bus is monitored by a bus monitor (i.e., a bus monitor) module, the obtained data bandwidth information is compared with the total bandwidth of the AMBA bus to determine whether to adjust the design parameters of the IP module or adjust the bus architecture of the SoC to be tested. If the adjustment is needed, the design of the IP module is changed to change the IP characteristic or the SoC bus architecture, then the verification is carried out through the UVM verification platform again based on the changed design, and the steps are repeated until the requirements are met.

In this embodiment, the step of determining whether to adjust the design parameter of the IP module or adjust the bus architecture of the SoC to be tested may specifically be as follows: and acquiring data bandwidth values of all IP modules on the AMBA bus, and summing the data bandwidths of all the IP modules to obtain the total bandwidth simulation Bsum. And comparing the analog bandwidth sum Bsum with the total bandwidth Ben of the AMBA bus. And when the total bandwidth Bsum is less than or equal to the total bandwidth Ben, judging that the design of the IP module meets the requirement without adjusting the design parameters of the IP module or the bus architecture of the SoC to be tested. When the total bandwidth Bsum of the simulation is greater than the total bandwidth Ben, it is determined that the design of the IP module does not meet the requirement, and the design parameters of the IP module or the bus architecture of the SoC to be tested need to be adjusted.

In this embodiment, a constraint file generation unit may be further disposed corresponding to the SoC to be tested.

The constraint file generating unit is configured to: and after the data stream characteristics of the IP module are obtained, storing the corresponding read-write operation parameter information into a template file with a general format, and generating the constraint file from the template file through a constraint compiling script.

The data stream characteristics may specifically include an IP module name, a bus interface type, and read/write operation parameters of bus interface data.

The read-write operation parameters may include data, address, read-write type, read-write ratio, burst length and ratio information in read-write operation, and the like. Correspondingly, the random read-write transmission packet generated according to the constraint file may include data, address, read-write type, read-write ratio, burst length and ratio information in read-write operation.

Referring to fig. 2, the template file is preferably an excel file, and design parameter information of the IP module is recorded by an excel table. The constraint compilation script is preferably a python script.

Preferably, the data structure of the excel file is configured in the format shown in fig. 3, and in this case, the preset fields of the table include a module name field, a read/write type field, and a duty ratio field for each burst length.

As an example, it is assumed that a module a1 is integrated in the SoC to be tested, and the module a1 is an AXI bus interface type.

Firstly, dividing the data stream characteristic requirements of the IP module according to the chip application scene. Specifically, for an IP module (usually, a third-party IP module or a past self-research IP module) with historical simulation data, data stream characteristics can be given according to the historical simulation data; if the IP module is an IP module without historical simulation data (usually, a newly developed IP module), a data flow characteristic requirement may be formulated by a user, and a bus port data flow characteristic of the IP module may be obtained according to the requirement. Thus, the data flow characteristic requirements of the IP module can be refined according to the chip application scene requirements.

For example, the aforementioned a1 module is an IP module (usually, a third-party IP module or a past self-developed IP module) with historical simulation data, and the data stream characteristics of the module a1, that is, the data characteristics of the AXI transmission, can be obtained by analyzing the historical simulation data, where the data stream characteristics include read/write operation parameter information of the bus interface data of the module a 1. For example, the read-write ratio of the obtained transmission data is 6: 4. In a read operation, the Burst length (i.e., Burst _ len) ranges from 1 to 16, where Burst _ len is 73% for 16, 25% for 8, 1.8% for 4, 0.2% for 1, and 0% for the rest of Burst _ len. In the write operation, Burst _ len also ranges from 1 to 16, where Burst _ len is 68% for 16, 28% for 8, 3% for 4, 1% for 1, and 0% for the rest.

After the data characteristics are obtained, writing the read-write operation parameter information into a preset excel table, which is shown in fig. 3; and then generating a constraint file through the python script, and providing the constraint file to the UVM verification platform.

And the UVM verification platform randomizes the read-write transmission packet (transaction) by utilizing the constraint file to generate a random read-write transmission packet (transaction). And then, sending the generated read-write transmission packet (transaction) to a Master VIP (Master VIP) corresponding to the A1 module, wherein data transmission simulation on a system bus (bus) is realized through the Master VIP.

Specifically, after the data bandwidth information of the IP module on the AXI bus is acquired by the bus monitor module, the acquired data bandwidth information is compared with the total bandwidth of the AXI bus to determine whether to adjust the design parameters of the IP module or adjust the bus architecture of the SoC to be tested.

By way of example, an IP block on an AXI bus such as in fig. 2 includes the aforementioned block a1, as well as other IP blocks: module A2, … …, AN, wherein N is AN integer greater than or equal to 2. For example, N =3, that is, the module a1, the module a2, and the module A3 are included, the data bandwidths corresponding to the modules are the bandwidth a1, the bandwidth a2, and the bandwidth A3, respectively, and after performing sum operation on the data bandwidths of the IP modules on the AXI bus, the analog bandwidth sum Bsum = bandwidth a1+ bandwidth a2+ bandwidth A3 may be obtained, and the analog bandwidth sum Bsum is compared with the total bandwidth Ben of the AXI bus. When the total bandwidth Bsum of the simulation is greater than the total bandwidth Ben, it is determined that the design of the IP module does not meet the requirement, and the design parameters of the IP module or the bus architecture of the SoC to be tested need to be adjusted.

And finally, verifying the design based on the changed design by the UVM verification platform again, and repeating the steps until the requirements are met. At this time, an IP module setting unit and an SoC bus architecture setting unit may be further provided corresponding to the SoC to be tested. The IP module setting unit is used for collecting the design parameter information of the IP module. The SoC bus architecture setting unit is used for acquiring design parameter information of a system bus architecture of the SoC.

The constraint file generating unit is connected with the IP module setting unit. The IP block setting unit is configured to: and when the design parameter information of the IP module is adjusted by the user, the adjusted design parameter information of the IP module is acquired and sent to the constraint file generating unit.

And the constraint file generating unit can generate a new constraint file after receiving the design parameter information of the adjusted IP module and send the new constraint file to the UVM verification platform to verify the design of the adjusted IP module.

The SoC bus architecture setting unit is connected with the UVM verification platform. The SoC bus architecture setup unit is configured to: when the design parameter information of the system bus architecture is adjusted by a user, the adjusted design parameter information of the system bus architecture is obtained and sent to the UVM verification platform.

And after receiving the adjusted design parameter information of the system bus architecture, the UVM verification platform can update the parameter information of the bus architecture and trigger verification.

The invention establishes a UVM verification platform simulation SoC bus architecture by utilizing the VIP component of AMBA at the SoC terminal. Specifically, firstly, according to the characteristic requirements corresponding to the IP module, after constraint randomization is performed on a data packet (transaction), the data packet is sent to the main VIP corresponding to the IP module to simulate the behavior of the IP bus, so that rapid modeling of the behavior of the IP bus is realized; then, whether the system design meets the requirements is verified through a simulation case (case).

The technical scheme can be used for evaluating the performance characteristics of the chip at the initial stage of chip design and development so as to shorten the research and development period and reduce the risk of the system. Optionally, the UVM verification platform may include a VIP verification mode and an RTL verification mode, and performs mode switching according to a mode switching instruction of a user or a system. Therefore, in the later stage of chip design and development, after the IP module is completed, whether the design of the IP module meets the requirement can be verified on an IP local end (local). When the IP module needs to run in an actual scene on the SoC bus architecture, the verification platform may also automatically switch the VIP mode to the RTL mode, and run an actual scene case (case) in the RTL mode.

The invention further provides a performance verification method for the AMBA bus architecture chip. The method comprises the following steps:

s100, building a UVM verification platform at a SoC end to be tested by using a VIP assembly of AMBA, wherein an AMBA bus is adopted in the SoC to be tested as a bus framework of on-chip communication, and an IP module is integrated in the SoC to be tested;

s200, acquiring design parameter information of the IP module, generating a constraint file, and sending the constraint file to the UVM verification platform; the constraint file is used for configuring read-write operation parameter information of the bus interface data of the IP module;

and S300, generating a random read-write transmission packet by the UVM verification platform according to the constraint file, sending the generated read-write transmission packet to the main VIP of the IP module, simulating the behavior of the IP bus through the main VIP and monitoring transmission data on the AMBA bus.

S400, in the monitoring process, after the data bandwidth information of the IP module on the AMBA bus is acquired through the bus monitor module, the acquired data bandwidth information is compared with the total bandwidth of the AMBA bus to judge whether the design parameters of the IP module need to be adjusted or the bus architecture of the SoC to be tested needs to be adjusted.

When it is determined that no adjustment is required (i.e., performance requirements are met), the verification is ended. When it is determined that adjustment is required (i.e., performance requirements are required to be met), the design of the IP module is changed to change the IP characteristics or change the SoC bus architecture, and then the step S200 is executed, and verification is performed again through the UVM verification platform based on the changed design, and the steps are repeated until the performance requirements are met.

In this embodiment, preferably, the step of determining whether to adjust the design parameter of the IP module or adjust the bus architecture of the SoC to be tested may be as follows:

acquiring data bandwidth values of all IP modules on an AMBA bus, and carrying out sum operation on the data bandwidth of each IP module to obtain a simulation bandwidth sum Bsum;

comparing the analog bandwidth sum Bsum with the total bandwidth Ben of the AMBA bus; when the total bandwidth Bsum is less than or equal to the total bandwidth Ben, judging that the design of the IP module meets the requirement without adjusting the design parameters of the IP module or the bus architecture of the SoC to be tested; when the total bandwidth Bsum of the simulation is greater than the total bandwidth Ben, it is determined that the design of the IP module does not meet the requirement, and the design parameters of the IP module or the bus architecture of the SoC to be tested need to be adjusted.

In this embodiment, before step S100, the method may further include the steps of: and dividing the data stream characteristic requirements of the IP module according to the chip application scene. Specifically, for an IP module with historical simulation data in a chip, after data stream characteristic information provided by the historical simulation data is acquired, the data stream characteristic information is compared with a preset data stream characteristic requirement, and when the data stream characteristic information and the preset data stream characteristic requirement are judged to be in accordance, the bus port data stream characteristic of the IP module is acquired from the historical simulation data; for the IP module without historical simulation data, collecting the data flow characteristic requirement formulated by a user, and acquiring the bus port data flow characteristic of the IP module according to the requirement.

Other technical features are referred to in the previous embodiments and are not described herein.

In the foregoing description, the disclosure of the present invention is not intended to limit itself to these aspects. Rather, the various components may be selectively and operatively combined in any number within the intended scope of the present disclosure. In addition, terms like "comprising," "including," and "having" should be interpreted as inclusive or open-ended, rather than exclusive or closed-ended, by default, unless explicitly defined to the contrary. All technical, scientific, or other terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs unless defined otherwise. Common terms found in dictionaries should not be interpreted too ideally or too realistically in the context of related art documents unless the present disclosure expressly limits them to that. Any changes and modifications of the present invention based on the above disclosure will be within the scope of the appended claims.