Bus-driven chip simulation stimulus model for ip unit level verification

Abstract

The application discloses a bus-driven chip simulation excitation model for IP unit level verification, which is realized through the following processes: S1, replacing an IO register access sequence of a system software driver; S2, replacing a register timing sequence guarantee function of the driver; and S3, replacing a test excitation initialization process of a test machine, and directly calling a verification program entrance of the system software.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of chip simulation, in particular to a bus-driven chip simulation excitation model for IP unit level verification, and more particularly to a bus-driven chip simulation excitation model for using arbitrary device driver software in IP unit level verification through a software architecture / driver abstraction layer. BACKGROUND

[0002] IP (Intellectual Property Core) is also known as IP core, which is a mature design of a circuit module with independent functions in a chip. Common IP unit level verification usually uses UVM (Universal Verification Methodology) bus excitation to control the register interface of IP. A test bench includes a design IP (such as Design IP in Figure 1 ), a verification IP (such as Verification IP in Figure 1 ), and a bus excitation sequence of a bus function model. The bus function works under the clock frequency generated by the test bench to drive the design IP and the verification IP to interact, and the function of the design IP is checked through the verification IP.

[0003] However, a commonly used open source operating system such as Linux can usually only support one CPU architecture abstraction, so it is not possible to directly use the driver software of an arbitrary device as a bus function model excitation for chip simulation. SUMMARY

[0004] To solve the above problems, the present application provides a bus-driven chip simulation excitation model for IP unit level verification, which realizes a software layer of CPU architecture abstraction through a DPI (Direct Programming Interface) interface to convert the hardware driver in the open source operating system to be used as a bus function model excitation for chip simulation. Since the native C (C language implementation of native method) used is faster than the UVM method, it can also provide a simulation speed 50% faster than the traditional UVM method.

[0005] To achieve the above purpose, the present application provides a bus-driven chip simulation excitation model for IP unit level verification, which is realized by the following process:

[0006] Step S1: replace the IO register access sequence of the system software driver;

[0007] Step S2: replace the register timing sequence guarantee function of the driver program;

[0008] Step S3: replace the test excitation initialization process of the test machine, and directly call the verification program entry of the system software.

[0009] In an embodiment of the present application, step S1 includes:

[0010] Step S1.1: use the Verilog language to implement and IP simulation frequency associated bus master read-write tasks;

[0011] Step S1.2: convert the bus master read-write tasks into C language callable IO read-write functions through the DPI interface of SystemVerilog;

[0012] Step S1.3: adopt the following method to implement access to the same register offset of multiple address spaces outside the IP:

[0013] Different base addresses are specified for different address spaces, and then different bus master read-write tasks are called according to the different incoming addresses in any read / write RTL sequence, that is, address decoding is added in RTL; or

[0014] Different bus master read-write tasks are provided and expressed as different C language functions, and then different address spaces are called according to different base addresses at the C language end;

[0015] Step S1.4: monitor whether there is a timing operation in the Verilog language that can push the chip simulation loop forward to execute when the IO read-write function is called by C language.

[0016] In an embodiment of the present application, step S2 includes:

[0017] Step S2.1: use the Verilog language to implement and IP simulation frequency associated counters;

[0018] Step S2.2: convert the counters into C language callable timing functions through the DPI interface of SystemVerilog;

[0019] Step S2.3: monitor whether there is a timing operation in the Verilog language that can push the chip simulation loop forward to execute when the timer function is called by C language.

[0020] In an embodiment of the present application, the system software needs to have the following characteristics:

[0021] The system software includes an architecture abstraction layer;

[0022] The system software comprises a hardware driver abstraction layer; and / or

[0023] The system software comprises configurable capabilities.

[0024] The bus-driven chip simulation excitation model for IP unit level verification provided by the present application has at least the following advantages compared to the prior art:

[0025] 1) The timing (Tick) hardware is added to realize the delay function of the system software;

[0026] 2) The bus sequence (Bus sequencer) of the bus function model is converted to realize the IO access (read, write) function of the system software;

[0027] 3) The initialization process of the test platform is added to directly call the test entry of the system software through the DPI interface;

[0028] 4) The frequency generator of the test platform of the present application can provide a reference clock for the clock tick (Tick) hardware and the bus sequence (Bus sequencer) hardware. BRIEF DESCRIPTION OF DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of these drawings.

[0030] Figure 1 The model architecture diagram of an embodiment of the present application. DETAILED DESCRIPTION

[0031] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0032] Generally, a driver mainly comprises register IO (input / output) access sequence (read, write) and timing guarantee (delay) between register access. Therefore, the present embodiment realizes direct operation of IP hardware by adding the following parts of system software and IP unit level verification test platform combined with the configuration of each part that needs to be modified:

[0033] 1) increase clock tick hardware, allow system software to access clock tick hardware through DPI interface to get reference time of simulation environment to realize timing function of system software;

[0034] 2) convert bus sequence of bus function model, allow system software to access bus sequence through DPI interface to realize IO access function of system software;

[0035] 3) increase initialization flow of test machine, directly call test entry of system software through DPI interface;

[0036] 4) frequency generator of test machine needs to provide reference clock for clock tick hardware and bus sequence hardware.

[0037] Figure 1 For the model architecture diagram of an embodiment of the present application, as shown in the figure, the embodiment provides a bus-driven chip simulation excitation model for IP unit level verification, which is realized through the following process: Figure 1

[0038] Step S1: replace IO register access sequence of system software driver;

[0039] In the embodiment, step S1 includes:

[0040] Step S1.1: use Verilog language to realize read-write task of bus master (which can be regarded as master part) associated with IP simulation frequency; see modification of Test Bench: Bus Sequencer in Figure 1 , wherein Verilog language generally refers to Verilog HDL, which is a hardware description language (HDL: Hardware Description Language) to describe structure and behavior of digital system hardware in text form. It can represent logic circuit diagram, logic expression and logic function completed by digital logic system.

[0041] Step S1.2: convert bus master read-write task into IO read-write function which can be called by C language through DPI interface of SystemVerilog; for example, it can be converted into readb, readw, readl, writeb, writew, writel, etc. See Figure 1 ​The modification of arch / svdpi, wherein SystemVerilog is abbreviated as SV language, is a language built on the basis of Verilog language.

[0042] Step S1.3: Access to the same register offset of multiple address spaces outside the IP is realized by the following method:

[0043] Different base addresses are specified for different address spaces, and then different bus master read / write tasks are called according to the different incoming addresses in any read / write (readX, writeX) RTL (Register Transfer Level, also called register transfer level) sequence, that is, address decoding is added in the RTL; or

[0044] Different bus master read / write tasks are provided and expressed as different C language functions, such as ahb_writeX, ahb_readX, axi_writel, axi_readX, and different address spaces are called according to different base addresses at the C language end;

[0045] Since an IP can have multiple address spaces outside, for example, the configuration space of DDR is AHB, and the data space of DDR is AXI. When IP unit level verification is performed, there is no base address, only the concept of register offset, so it is necessary to distinguish the access to the same register offset of different address spaces.

[0046] Step S1.4: Monitor whether there is a timing operation in the Verilog language that can push the chip simulation cycle forward when the IO read / write function is called by the C language.

[0047] Since the C language is a SystemVerilog specification when called, the Cycle of the simulation frequency will not be pushed forward, so attention should be paid to when the IO read / write function is called by the C language, the verilog has a timing operation that can push the chip simulation Cycle forward.

[0048] Through the above step S1 replacement, the bus sequence (Bussequencer) of the process conversion bus function model is completed.

[0049] Step S2: Replace the register timing sequence guarantee function of the driver;

[0050] In this embodiment, step S2 includes:

[0051] Step S2.1: Implement a counter associated with the IP simulation frequency in the Verilog language; seeFigure 1 Modification in TestBench:Tick.

[0052] Step S2.2: Convert the counter into a timing function that can be called by C language through the DPI interface of SystemVerilog; for example, it can be a tick function, see Figure 1 Modification in delay.

[0053] Step S2.3: Monitor whether there is a timing operation in the Verilog language that can push the cycle of the chip simulation forward when the timer function is called by the C language.

[0054] Since the C language is called when the monitoring cycle is specified in the SystemVerilog specification, the cycle of the simulation frequency does not advance, so attention should be paid to when the timer function is called by the C language, there is a timing operation in the Verilog language that can push the cycle of the chip simulation forward, otherwise, the pure C language continuous call of the timing function (such as the tick function) to achieve the timing guarantee (delay) between register access will never achieve the timing requirement and run to death (dead loop).

[0055] Through the replacement of step S2, the process of adding the clock tick (Tick) hardware in the model is completed.

[0056] Step S3: Replace the test bench test excitation initialization process, and directly call the verification program entry of the system software; the program entry may be system_main, see Figure 1 Modification in Test Bench:Initial.

[0057] Since the method of the embodiment can be combined with any system software without interrupt processing (for example, the bootloader is in a state without interrupt), therefore, further, if the system software (System Software) has the following characteristics, the transplantation will be very easy.

[0058] Through the above step S3, the process of adding the initialization flow of the test bench is completed.

[0059] In the embodiment, the system software needs to have the following characteristics:

[0060] System software contains architecture abstraction layer; usually system software with high architecture abstraction degree has architecture specific directory, for example, arch / arm64, arch / riscv directory of linux kernel, in such system software, an architecture for simulation, for example, arch / svdpi, is implemented to contain the implementation of register IO access replacement in step S1, other functions required by arch / svdpi are simulated by calling functions of local host (for example, x86 server) C library, similar to (UM simulator of Linux kernel);

[0061] System software contains hardware driver abstraction layer; usually system software with high driver abstraction degree allows to add specific timing hardware implementation, for example, drivers / clocksource directory of linux kernel, in such system software, a timing hardware for simulation is implemented to contain the implementation of register timing sequence replacement in step S2; and / or

[0062] System software contains configurable capability. System software preferably contains strong configurable capability, so that minimal configuration is made for target IP, only containing DPI interface architecture, tested hardware IP, driver and corresponding protocol stack of verification IP, system entry system_main can be configured as test program entry suitable for simulation stimulus, so that the highest execution efficiency can be achieved when system software and simulation hardware are combined.

[0063] The bus-driven chip simulation stimulus model for IP unit level verification provided by the present application has at least the following advantages compared with the prior art: the timing (Tick) hardware is added to realize the delay function of system software; the bus sequence (Bus sequencer) of the bus function model is converted to realize the IO access (read, write) function of system software; the initialization process of the test platform is added, so that the test entry of system software can be directly called through the DPI interface; 4) the frequency generator of the test platform of the present application can also provide reference clock for the timing (Tick) hardware and the bus sequence (Bus sequencer) hardware.

[0064] Those skilled in the art can understand that the modules or processes in the drawings are not necessarily required for the implementation of the present application.

[0065] Those skilled in the art can understand that the modules in the device in the embodiment can be distributed in the device in the embodiment according to the description of the embodiment, or can be changed and located in one or more devices different from the embodiment. The modules in the above embodiment can be combined into one module, or can be further split into multiple sub-modules.

[0066] It should be pointed out finally that the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features therein can be replaced equivalently; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A bus-driven chip simulation stimulus model for IP unit level verification, characterized by, The process is implemented as follows: Step S1: replace the IO register access sequence of the system software driver, including: Step S1.1: implement the bus master read-write task associated with the IP simulation frequency using the Verilog language; Step S1.2: convert the bus master read-write task into an IO read-write function that can be called by C language through the DPI interface of SystemVerilog; Step S1.3: implement the access to the same register offset of multiple address spaces outside the IP by the following method: specify different base addresses for different address spaces, and then call different bus master read-write tasks according to the different incoming addresses in any read / write RTL sequence, that is, add address decoding in RTL; or provide different bus master read-write tasks and represent them as different C language functions, and then call different address spaces according to different base addresses on the C language side; Step S1.4: monitor whether there is a timing operation in the Verilog language that can push the chip simulation loop forward to execute when the IO read-write function is called by C language; Step S2: replace the register timing sequence guarantee function of the driver; Step S3: replace the test excitation initialization process of the test board and directly call the verification program entry of the system software.

2. The bus-driven chip emulation stimulus model for IP unit level verification according to claim 1, wherein, Step S2 includes: Step S2.1: implement the counter associated with the IP simulation frequency using the Verilog language; Step S2.2: convert the counter into a timing function that can be called by C language through the DPI interface of SystemVerilog; Step S2.3: monitor whether there is a timing operation in the Verilog language that can push the chip simulation loop forward to execute when the timer function is called by C language.

3. The bus-driven chip emulation stimulus model for IP unit level verification according to claim 1, wherein, The system software needs to have the following characteristics: The system software includes an architecture abstraction layer; The system software includes a hardware driver abstraction layer; and / or The system software includes configurable capabilities.

Images