WO2024046362A1 - 验证系统、验证方法、电子设备以及存储介质 - Google Patents

验证系统、验证方法、电子设备以及存储介质 Download PDF

Info

Publication number
WO2024046362A1
WO2024046362A1 PCT/CN2023/115777 CN2023115777W WO2024046362A1 WO 2024046362 A1 WO2024046362 A1 WO 2024046362A1 CN 2023115777 W CN2023115777 W CN 2023115777W WO 2024046362 A1 WO2024046362 A1 WO 2024046362A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
verification
function
storage unit
interface
Prior art date
Application number
PCT/CN2023/115777
Other languages
English (en)
French (fr)
Inventor
井晓琳
张地
薛劲恒
卢山
王剑
Original Assignee
北京有竹居网络技术有限公司
脸萌有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京有竹居网络技术有限公司, 脸萌有限公司 filed Critical 北京有竹居网络技术有限公司
Publication of WO2024046362A1 publication Critical patent/WO2024046362A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software

Definitions

  • Embodiments of the present disclosure relate to a verification system, a verification method, an electronic device, and a storage medium.
  • SoC System On Chip
  • VLSI Very Large Scale Integration
  • EDA Electronic Design Automation
  • Hardware acceleration verification technology verifies the chip design through a hardware simulator, which maps the design under test (DUT) to a processor array or field programmable gate array (Field Programmable Gate Array, FPGA), and then Mapping equivalent systems for verification.
  • DUT design under test
  • FPGA field programmable gate array
  • the speed of hardware accelerated verification methods is qualitatively improved compared to software simulation.
  • the average software simulation rate is, for example, 1KHz, while the average hardware acceleration simulation verification method can reach, for example, 2MHz, which greatly improves verification efficiency.
  • At least one embodiment of the present disclosure provides a verification system, including a simulation verification device and a first part and a second part respectively created on the simulation verification device, wherein the first part includes a third part respectively connected to the object to be tested.
  • the multiple object interfaces include memory access interfaces.
  • the second slave module includes a storage unit, and the storage unit is connected to the memory access interface.
  • the second part includes a first direct programming interface, a second direct programming interface, a function library module and a test case module, the test case module is configured to provide at least one test case;
  • the first direct programming interface and The first main module communicates, and the first direct programming interface is configured to: in response to running the test case, call at least one first function in the function library module to implement the register of the module under test front door access;
  • the second direct programming interface communicates with the storage unit of the first part, and the second direct programming interface is configured to: in response to running the test case, call the function library module At least one second function to implement backdoor access to the storage unit.
  • At least one embodiment of the present disclosure also provides a verification method based on the verification system as described above, including: performing register transfer level code compilation based on the module under test; based on the first part, the object under test, and the The module to be tested, the first main module and the second slave module are comprehensively compiled to obtain the compiled first part; the usage mode of the simulation verification device is selected, and the compiled data is compiled according to the usage mode.
  • At least one embodiment of the present disclosure provides an electronic device, including: a processing module and a memory, wherein a computer program is stored on the memory, and when the computer program is executed by the processing module, any of the above items are implemented. the verification method described above.
  • At least one embodiment of the present disclosure provides a computer-readable storage medium, wherein a computer program is stored in the storage medium.
  • a computer program is stored in the storage medium.
  • the verification method as described in any of the above examples is implemented. .
  • Figure 1 is a schematic block diagram of a verification system provided by some embodiments of the present disclosure
  • Figure 2 is a schematic block diagram of the software side of the verification system provided by some embodiments of the present disclosure.
  • Figure 3 is a schematic block diagram of the first main module of the verification system provided by some embodiments of the present disclosure.
  • Figure 4 is a schematic diagram of the address space of the first master module and the second slave module provided by some embodiments of the present disclosure
  • Figure 5 is a flow chart of a verification method provided by some embodiments of the present disclosure.
  • Figure 6 is a flow chart of an execution process of step S5 of the verification method in Figure 5;
  • Figure 7 is a flow chart of a verification method provided by other embodiments of the present disclosure.
  • Figure 8 is a block diagram of an electronic device provided by some embodiments of the present disclosure.
  • hardware simulation acceleration verification platforms include FPGA-based verification platforms, and FPGA-based verification platforms include HAPS or ZEBU.
  • FPGA-based verification platform is not suitable for functional simulation acceleration that replaces EDA simulation due to limitations such as capacity limitations, long synthesis time, difficulty in debugging, the need to manually divide large systems, and the need to modify the clock tree.
  • UVM Universal Verification Methodology
  • test platform needs to be written in a synthesized form and integrated into the simulation accelerator.
  • the reusability is very low.
  • Different test platforms need to be rewritten when combined with the simulation accelerator. , analysis and debugging, the workload is relatively large.
  • At least one embodiment of the present disclosure provides a verification system, including a simulation verification device and a first part and a second part respectively created on the simulation verification device; the first part includes a first main module respectively connected to the object to be tested and at least one The second slave module; the object to be tested includes the module to be tested and multiple object interfaces connected to the periphery of the module to be tested.
  • the multiple object interfaces include memory access interfaces.
  • the second slave module includes a storage unit, and the storage unit is connected to the memory access interface.
  • the second part includes a first direct programming interface, a second direct programming interface, a function library module and a test case module, the test case module is configured to provide at least one test case;
  • the first direct programming interface communicates with the first main module, and the A direct programming interface is configured to: in response to running the test case, call at least one first function in the function library module to achieve front-door access to the register of the module under test;
  • a second direct programming interface communicates with the storage unit of the first part, and
  • the second direct programming interface is configured to: in response to running the test case, call at least one second function in the function library module to implement backdoor access to the storage unit.
  • the verification system of the above embodiments of the present disclosure can realize the synchronization of the software side and the hardware side of the verification system, and facilitate the realization of register reading, writing and storage in the functional verification of the module under test. For operations such as unit memory access, simulation consumes less time, and the chip verification efficiency is improved. It can realize reusable verification of the chip at the system level and/or module level. Before application The scenery is extensive.
  • Figure 1 is a schematic block diagram of a verification system provided by some embodiments of the present disclosure.
  • Figure 2 is a schematic block diagram of the software side of the verification system provided by some embodiments of the present disclosure.
  • the verification system 1000 includes a simulation verification device 100 and a first part 200 and a second part 300 respectively created on the simulation verification device 100 .
  • the first part 200 is the hardware side configured to be created based on the Hardware Description Language (HDL).
  • the second part 300 is the software side, which is configured to be created based on a behavioral modeling language.
  • hardware description languages include Verilog, SystemVerilog, etc.
  • behavioral modeling languages include C language or CPP language (also called C++ language), etc.
  • the first part 200 includes a first master module 210 and at least one second slave module 220 that are respectively connected to the object to be measured 230 .
  • the object to be tested 230 includes a module to be tested 231 and a plurality of object interfaces connected to the periphery of the module to be tested 231 .
  • the plurality of object interfaces includes at least one memory access interface 232 .
  • the second slave module 220 includes a storage unit 221 , and the storage unit 221 is connected to the memory access interface 232 .
  • the module under test 231 is the design under test (Design Under Test, DUT).
  • DUT Design Under Test
  • RTL Register Transfer Level, register transfer level
  • the second part 300 includes a first direct programming interface 310 , a second direct programming interface 320 , a function library module 330 and a test case module 340 .
  • Test case module 340 is configured to provide at least one test case.
  • the first direct programming interface 310 and/or the second direct programming interface 320 are both direct programming language interfaces DPI (Direct Programming Interface), which are used in hardware description languages (such as SystemVerilog) and programming languages for software (such as C/C++) interface for calling each other.
  • DPI Direct Programming Interface
  • hardware description languages such as SystemVerilog
  • programming languages for software such as C/C++
  • the function library module 330 is configured to create a function library based on multiple functions for use by other programs.
  • the function library module 330 may use a static library.
  • the function library module 330 internally includes at least one first function and at least one second function, wherein the first function can realize the configuration of the register when called and used, and the second function can realize the memory access of the storage unit when called and used. .
  • the first direct programming interface 310 communicates with the first main module 210, and the first direct programming interface 310 is configured to: in response to running a test case originating from the test case module 340, call the function library module 330 At least one first function in to achieve front-door access to the register of the module under test 231.
  • front-door access includes front-door read data operations and/or front-door write data operations
  • the first function includes functions related to register reading and/or writing.
  • the second direct programming interface 320 communicates with the storage unit 221 of the first part 200, and the second direct programming interface 320 is configured to: in response to running a test case originating from the test case module 340, call the function library At least one second function in module 330 to implement backdoor access to storage unit 221.
  • the backdoor access includes a backdoor data loading operation and/or a backdoor data exporting operation
  • the second function includes a storage unit loading and/or exporting function.
  • the "front door access" of the embodiments of the present disclosure refers to simulating the CPU (Central Processing Unit, Central Processing Unit) to issue read and write instructions on the bus through the register configuration bus (such as AMBA protocol), and following the bus timing to DUT The actual value of the register is read and written accessed.
  • Front-door access involves real RTL transmission and front-door access relies on the bus timing protocol for transmission. Therefore, front-door access consumes simulation time. For example, front door access is not read-write by domain.
  • backdoor access in embodiments of the present disclosure refers to an access method that directly reads a two-dimensional array of storage cells. Backdoor access does not consume simulation time. For example, backdoor access can be read and written by domain.
  • the verification system of the above embodiments of the present disclosure can realize the synchronization of the software side and the hardware side of the verification system, and facilitate the realization of register reading, writing and storage in the functional verification of the module under test. Unit access, etc., the simulation consumes less time, the verification efficiency of the chip function is improved, and the system-level and module-level reusable verification of the chip can be realized, and the application prospects are wide.
  • the object under test 230 of the first part 200 is the top layer of the hardware side of the verification system 100.
  • the module under test 231 of the object under test 230 includes the IP (Intellectual Property) module of the SoC chip.
  • the module to be tested 231 may be an independent IP in the SOC to be verified by the verification system 100 .
  • the SOC may be based on the microarchitecture of instruction sets such as X86, ARM, RISC-V, etc., and the embodiments of the present disclosure are not limited to this.
  • the module to be tested 231 has universality and is suitable for key IP in the chip.
  • the module to be tested 23 includes but is not limited to GPGPU (General Graphics Processing Unit). The embodiments of the present disclosure are not limited and repeated here.
  • the verification system of the above embodiments of the present disclosure can be applied to the simulation verification acceleration and software bare metal development of IP level modules in SoC, and the time required for simulation verification is greatly reduced.
  • the module to be tested 231 in the embodiment of the present disclosure may belong to the IP module level in some scenarios, and may also belong to the subsystem level in other scenarios. This is not limiting and does not affect the scope of the present disclosure.
  • first master module and the second slave module in the embodiment of the present disclosure are respectively called the master module or the slave module relative to the object to be tested. This is just a naming method. To facilitate the clarity and conciseness of the description of the present disclosure, the embodiments of the present disclosure are not limited thereto, and the protection scope of the embodiments of the present disclosure is not limited thereby.
  • the simulation verification device 100 includes a first processor and the first processor includes a plurality of second processors connected in parallel, that is, the second processor is a sub-processor relative to the first processor.
  • simulation verification equipment includes Cadence's Palladium device.
  • the underlying architecture of the Palladium device is a CPU processor and an application-specific integrated circuit.
  • the processor of the Palladium device is connected in parallel with a large number of processors, so that simulation verification can be accelerated through parallel channels.
  • Embodiments of the present disclosure perform hardware simulation accelerated verification based on simulation verification equipment such as Palladium equipment, which can keep the chip RTL compatible with fewer changes; have excellent debugging performance and high signal visibility; and have high platform compatibility and can support SystemVerilog or System C Or System CPP; and there is no need to manually divide the SoC design, and it does not require much additional manpower investment, etc., which can well meet the chip project's verification time requirements and chip delivery quality.
  • simulation verification equipment such as Palladium equipment
  • simulation verification device used in the verification system of the embodiment of the present disclosure is not limited to the Palladium device, but can also be other simulation verification equipment built based on the processor.
  • the embodiment of the present disclosure will not limit or repeat the description.
  • the second part 300 is configured to be created based on the C language or the CPP language.
  • the second part 300 is a software side running on, for example, Cadence's compilation software Xcelium. In this way, the verification system of the disclosed embodiment can easily implement the execution of relevant instructions after compiling the C language or CPP language code. It is widely used and facilitates the development work of R&D personnel.
  • the first main module 210 is used to generate read and/or write instructions and configure the registers of the module under test 231 and generate a reset, such as a global reset.
  • the second part 200 also includes a driving module 350 for driving the first main module 210 of the first part 200, so that the first main module 210 configures the register of the module under test 231 and performs global operations. reset.
  • the first master module 210 and the second slave module 220 are AVIP (Accelerated Verification IP) based on the verification unit component (Verification IP, VIP) and designed for the simulation verification device 100.
  • AVIP Accelerated Verification IP
  • Verification IP Verification IP
  • the first main module 210 includes a main module of an advanced microprocessor bus architecture.
  • the module can also be called AMBA MASTER, that is, the first master module 210 supports the AMBA standard bus protocol.
  • the driving module 350 can also be called AMBA MASTER Driver.
  • the second slave module 220 includes an advanced microprocessor bus architecture slave module, which can also be called AMBA SLAVE, that is, the second slave module 220 supports the AMBA standard bus protocol.
  • the verification system of the above embodiments of the present disclosure enables wider bus protocol verification at the module level and subsystem level by using AVIP that can support multiple standard bus protocols.
  • the first part 200 also includes a clock excitation source module 240.
  • the clock excitation source module 240 is used to provide a system clock signal on the hardware side for use by the DUT and the like.
  • the clock signal may have a clock frequency of 1GHZ. This is only exemplary and not a limitation of the disclosure.
  • the plurality of object interfaces of the object under test 230 also include at least one of a first interface 233a, a second interface 233b, a third interface 233c, and a fourth interface 233d.
  • the first interface 233a is connected to the clock excitation source module 240 to receive the clock signal.
  • the verification system of the present disclosure can be driven by a global clock, which facilitates the functionality, performance, and stability of synchronized digital systems.
  • the second interface 233b is configured to receive an interrupt request signal.
  • the interrupt request signal is used to stop the current working state of the relevant hardware and switch to the operation task corresponding to the interrupt request signal, and then switch back after the processing of the operation task is completed, thereby avoiding signal conflicts.
  • the first main module 210 is connected to the third interface 233c for configuring the register of the module under test 231 .
  • the first main module 210 is connected to the fourth interface 233d for resetting the first part 200 .
  • the number of memory access interfaces 232 is two
  • the number of second slave modules 220 is two
  • each second slave module 220 includes a storage unit 221 .
  • the storage unit 221 and the memory access interface 232 are in one-to-one correspondence, which can form a data transmission path between each storage unit 221 and the module to be tested 231, thereby realizing front-door access to the register.
  • the storage unit 221 of the second slave module 220 is used to store register data, that is, the main role of the second slave module 220 in the verification system 100 is as a memory of the verification system.
  • the embodiment of the present disclosure can implement the memory access interface 232. The data written by the front-door write operation is now stored in the storage unit 221.
  • the first part 200 may further include a rate matching bridge 250 , and the rate matching bridge 250 is configured to be connected to the second slave module 220 and the memory access interface 232 respectively.
  • the read and write rates can be converted and processed through the rate matching bridge 250, thereby avoiding the metastable state of cross-clock domain data transmission and clock signal mismatch between the module under test 231 and the memory unit 221. question.
  • the sources of data in the storage unit 221 of the second slave module 220 include two types.
  • the first method is to write data into the register of the module under test 231 through a front-door write operation and transfer it across the clock domain to the storage unit 221 of the second slave module 220 via the rate matching bridge 250 .
  • the second method is to import data into the storage unit 221 through a backdoor data loading operation.
  • the storage unit 221 of the second slave module 220 has a virtual storage space.
  • the present disclosure can allocate a part of the storage space to the storage unit 221 through the Palladium device. This is only illustrative and does not limit the embodiments of the present disclosure.
  • the first direct programming interface 310 includes a direct programming interface (C/C++DPI) based on C language or CPP language
  • the second direct programming interface 320 includes a one-time DPI based on C language or CPP language.
  • Accessible Direct Programming Interface MARG DPI
  • MARG DPI is a type of interface that is relatively more suitable for one-time storage and reading.
  • the embodiment of the present disclosure connects the software side and the hardware side of the verification system through the DPI interface. This not only enables the first main module 210 to complete the front-door access (such as front-door read and write operations) of registers of the AMBA bus through the CPP interface function of the DPI. , and based on the set MARG DPI, the storage unit 221 of the second slave module 220 can directly realize the backdoor access of the storage unit 221 by calling the CPP interface function corresponding to the MARG DPI, thereby realizing the data loading and data loading of the storage unit. Export.
  • the CPP interface function used in the embodiment of the present disclosure (such as the first function or the second function described above, for example, the first function may include functions related to register reading and/or writing, and the second function includes storage unit loading and/or or exported functions, etc.) are written and packaged in CPP language and are easy to call. It can realize more complex functions and test cases whose functions are more suitable for chip requirements. It also achieves synchronization between the software side and the hardware side, and greatly improves the efficiency of simulation acceleration. improve.
  • Figure 3 is a schematic block diagram of the first main module of the verification system provided by some embodiments of the present disclosure.
  • the first master module 210 includes a master core 211 and a third slave module 212 .
  • the third slave module 212 is embedded in the first master module 210, and the third slave module 212 is an embedded advanced peripheral bus slave module, that is, an embedded APB module.
  • the third slave module 212 in the embodiment of the present disclosure is called a slave module relative to the main core 211. This is just a naming method, and the embodiment of the present disclosure is not limited to this. , the protection scope of the embodiments of the present disclosure is not limited by this.
  • the main core 211 of the first main module 210 is an AVIP core, and the main core 211 of the first main module 210 includes synthesizable RTL code.
  • the main core 211 is connected to the first direct programming interface 310 and the third interface 233c respectively, so that the main core 211 obtains the register access instruction corresponding to the first function of the test case (that is, for the test case to be tested). Instructions for performing read or write operations on the registers of the module 231) are used to configure the registers of the module 231 under test.
  • the main core 211 of the first main module 210 obtains a register access instruction for configuring the register of the module under test 231 .
  • control data includes basic data required for reading or writing operations on registers, such as the base address of the memory and the base width of the memory. This is only exemplary and not a limitation of the disclosure.
  • the third slave module 212 of the first master module 210 is connected to the master core 211 and the fourth interface 233d respectively, so that the reset signal generated by the master core 211 can be transmitted to the fourth interface 233d for use.
  • Reset first part 200 For example, a reset needs to be performed before each test case starts running for simulation, so that the status of all cores and the status of all memories on the hardware side is the initial state.
  • the second slave module 220 when the second slave module 220 is an AMBA module, it can be instantiated into multiple AMBA modules of different types, such as an APB module, an AXI module, or an ACE module. This is only exemplary and not a limitation of the disclosure.
  • the AMBA parameters that need to be declared include at least one of the following: memory size, memory base address, and depth of the currently ongoing (Outstanding) operation that can be supported. This is only exemplary and not a limitation of the disclosure.
  • the first master module 210, the second slave module 220, and the third slave module 212 are respectively configured with independent storage spaces. For example, after the verification system 1000 completes the preliminary construction, it is necessary to allocate memory to various modules such as the first master module 210, the second slave module 220, and the third slave module 212. storage space.
  • Figure 4 is a schematic diagram of the address space of the first master module and the second slave module provided by some embodiments of the present disclosure.
  • the address offset of the first master module 210 is 0x0000_0000
  • the address offset of the third slave module 212 is 0x0010_0000 (1M Byte).
  • the address range of the first main module 210 includes 0x0000_0000 ⁇ 0x000F_FFFF with a size of 1MB and 0x0010_0000 ⁇ 0x001F_FFFF with a size of 1MB.
  • the address range of one of the two second slave modules 220 is 0x4000_0000 ⁇ 0x7FFF_FFFF and the size is 1GB
  • the address range of the other second slave module 220 is 0x8000_0000 ⁇ 0xFFFF_FFFF and The size is 2GB. This is only exemplary and not a limitation of the disclosure.
  • the second portion 300 also includes a configuration file.
  • the test case is configured to perform a case configuration based on at least one first function of the configuration file for front door access, or the test case is configured to perform a use case configuration based on at least one second function of the configuration file to perform backdoor access.
  • the function library module 330 includes a static library compiled and generated through a behavioral modeling language based on test cases and configuration files.
  • test cases provided by the test case module 340 include test0 to test3, and different test cases will call different functions to verify the functions that meet the requirements.
  • test_entry() is the entrance for users to edit test cases to be tested.
  • Configuration files (such as .cfg files) are called in test_entry() to complete the configuration of relevant test cases.
  • the verification system 1000 can provide users with APIs for front-door access and back-door access to configuration registers.
  • the configuration file is compiled by C/CPP to generate a static library user lib, which is further parsed by the API interface to complete, for example, reading and writing of registers.
  • the simulation acceleration verification of the above embodiments of the present disclosure uses test cases built based on C/CPP code, which makes the environment relatively simple and without complex methodologies.
  • the simulation environment can be quickly set up and the running speed is very fast.
  • the first function includes: at least one of the register read function reg_read, the register write function reg_write, the register read check function reg_read_check, the register write read and check function reg_write_check, and the register polling wake-up read function poll_reg_equal.
  • the function reg_write is used to directly write 32-bit data at a specific register address
  • the function reg_read is used to directly read 32-bit data at a specific register address.
  • the function reg_read_check is used to check whether the data written to a specific address register is the same as expected.
  • the data written to a specific address register can be the data written through the function reg_write.
  • the function reg_read_check first reads data from a specific address register, and then compares the read data with the expected data. If the comparison result is the same, the check passes. If the comparison result is not the same, the current operation will be stopped and an error will be reported. .
  • the function reg_read_check can be used to write data to a register at a specific address, and automatically compare the reading result with the expected result. This has a relatively high degree of automation and can improve the work efficiency of verification personnel.
  • function reg_write_check can also refer to function reg_read_check.
  • function reg_write_check also includes writing data in a specific address register, which will not be described again here.
  • the function poll_reg_equal is used to poll and read values from a specific address register multiple times until the value read from the specific address register is equal to the expected value; if not, continue reading until the number of reads exceeds the user limit.
  • Set the maximum number of polls for example, 10000
  • report an error and end polling if the value is read multiple times from the same address register but it is still different from the expected value, report an error and end the reading cycle.
  • the function poll_reg_equal can poll and wake up the relevant registers and check the register data in sequence when some registers need to be polled to wake up the registers before the second function performs backdoor access to the storage unit of the second slave module. Read and write results.
  • the second function includes: at least one of the storage unit polling wake-up read function poll_mem_equal, the storage unit initialization function mem_init, the storage unit data loading function mem_load, and the storage unit data export function.
  • the storage unit data export function includes the storage unit multi-byte read function or the storage unit data capture function mem_dump.
  • the data segment lengths read out by the function mem_dump and the storage unit multi-byte read function are different.
  • the function mem_dump reads The length of the data segment read out is greater than the length of the data segment read by the multi-byte read function of the storage unit.
  • the storage unit multi-byte read function includes the function mem_read32 or the function mem_read64.
  • the function mem_read32 is used to directly read out the 32-bit data of a specific memory unit address
  • the function mem_read64 is used to directly read out the 64-bit data of a specific memory unit address.
  • the function mem_dump can grab data from the storage unit and grab the data in the storage unit in hexadecimal format into a self-named hexadecimal format file (hex file).
  • the function mem_load loads a readable file in hexadecimal format into the verification system.
  • This hexadecimal format file is a two-dimensional array, with the address in the front and data in the back.
  • the function mem_load function loads each data into the corresponding storage space based on the address.
  • the function poll_mem_equal is used to poll and read the value from the storage unit at the specified address multiple times until the value read from the storage unit at the specific address is equal to the expected value; if the comparison result is not equal, continue reading until the number of reads exceeds the maximum number of polls set by the user (for example, 10000), an error will be reported and polling will end; if the value is read multiple times from the storage unit at the same address but it is still different from the expected value, an error will be reported. End reading cycle.
  • the function mem_init is used to initialize the storage unit within the used address range to prevent the remaining data in the storage unit after running the test case last time from affecting the running and result comparison of the next test case.
  • the function mem_init initializes the storage unit with a set address range. There are five main modes:
  • Mode 0 All values in the storage units are initialized to 0x0000_0000;
  • Mode 1 All values in storage units are initialized to 0xFFFF_FFFF;
  • Mode 2 The value of the storage unit is initialized to the value of each storage unit address
  • Mode 3 The value of the storage unit is initialized to a value starting from 0x0 and increasing by 0x4 each time;
  • Mode 4 The value of the storage unit is initialized to a value starting from 0 and increasing by 1 each time.
  • the function library module 330 may also include a file comparison function file_cmp and/or a reset function glb_rst.
  • the function file_cmp can compare two hex files to obtain the comparison results.
  • the user can specify the names of the two hex files that need to be compared in the file_cmp function definition.
  • the function glb_rst can reset the first part 200, resetting the module status in the first part 200.
  • each test case in the multiple test cases provided by the test case module 340 may not be exactly the same, and the function corresponding to each test case may be one or more, for example, each The test case can be any function or any combination of multiple functions described above.
  • the embodiments of the present disclosure are not limited to this, and it can be freely adjusted according to actual verification needs, which will not be described again here.
  • function library module 330 of the embodiment of the present disclosure are not limited to the above examples, and may also be other corresponding functions used to meet verification requirements, which will not be exhaustive and repeated here.
  • At least one embodiment of the present disclosure also provides a verification method, which can be implemented based on the verification system described in any of the above embodiments.
  • a verification method which can be implemented based on the verification system described in any of the above embodiments.
  • Figure 5 is a flow chart of a verification method provided by some embodiments of the present disclosure.
  • a verification method provided by at least one embodiment of the present disclosure includes steps S1 to S5.
  • Step S1 Compile the RTL code based on the module to be tested 231.
  • Step S2 Comprehensive compilation is performed based on the first part 200, the object to be tested 230, the module to be tested 231, the first master module 210, and the second slave module 220, and the compiled first part 200 is obtained.
  • Step S3 Select the usage mode of the simulation verification device 100, add at least one compilation option to the compiled first part 200 according to the usage mode, and call the first assembly tool to deconstruct the verification system 1000 to generate hardware for the simulation verification device 100.
  • Step S4 Compile the code of the behavioral modeling language for the second part 300.
  • Step S5 Run the compiled first part 200 and the second part 300 to obtain the verification results.
  • the verification method of the present disclosure also includes the following processes or steps: debugging according to the verification results, so that the verification passes.
  • the verification method of the present disclosure also includes the following process or step: configuring the verification results to be visualized on the simulation verification device 100, and the visualization method includes but is not limited to charts, texts, waveform diagrams, etc. This can reflect the verification results in a timely, convenient and accurate manner, which is conducive to the management and execution of verification work.
  • RTL code compilation based on the module to be tested 231 includes the following processes or steps: using a second compilation tool to compile the RTL file list and corresponding RTL files of the module to be tested 231, and generating a device including the object to be tested 230.
  • a DUT netlist in a certain format is generated, for example, a DUT netlist in vg format containing the object under test 230 is generated.
  • the generated DUT netlist is configured to run on the simulation verification device 100 .
  • the setting format of the DUT netlist in the embodiment of the present disclosure is The format is not limited to vg format, but can also be other types of formats, such as edif format, etc., and embodiments of the present disclosure do not limit this.
  • the second compilation tool includes Cadence's compilation tool vavlog or compilation tool vaelab.
  • Cadence's compilation tool vavlog or compilation tool vaelab.
  • step S2 comprehensive compilation is performed based on the first part 200, the object to be tested 230, the module to be tested 231, the first master module 210 and the second slave module 220 to obtain the compiled first part 200, including the following processes or steps :
  • the first part 200, the object to be tested 230, the module to be tested 231, the first main module 210, and the second slave module 220 (for example, the two second slave modules 220 in Figure 1 ) and the clock excitation source module 240 perform comprehensive compilation to obtain the compiled hardware side.
  • tertiary compilation tools include Cadence's Palladium-based vlan tool.
  • Cadence's Palladium-based vlan tool is only an example and is not a limitation of the present disclosure.
  • the objects of comprehensive compilation in the embodiment of the present disclosure not only include the first part 200, the object to be tested 230, the module to be tested 231, the first master module 210 and the second slave module 220, but also include, for example, compilation necessary Cadence AVIP files and other required peripheral test resources are comprehensively compiled. Since this is not the focus of the embodiments of the present disclosure, it will not be exhaustive and repeated here. Therefore, the compiled hardware side can be generated through the comprehensive compilation of this step.
  • step S3 select the usage mode of the simulation verification device 100, add at least one compilation option to the compiled first part 200 according to the usage mode for accelerator compilation, and call the first assembly tool to deconstruct the verification system to generate Simulate and verify the hardware information library of the device, including the following processes or steps: select the IXCOM mode of the Palladium device, add at least one compilation option to the compiled first part 200 according to the IXCOM mode, and call the first assembly tool to deconstruct the verification system 1000 , generate hardware information library (hardware lib).
  • the hardware information library contains the lib library of RTL, simulation environment, compilation environment and other information. This is only exemplary and not a limitation of the disclosure.
  • the embodiment of the present disclosure uses Palladium's IXCOM mode, which makes it more compatible with the non-integrated parts of the design, supports putting part of the design into simulation verification equipment, and is compatible with other modes, which can reduce the workload of verification and reduce costs. , improve verification efficiency.
  • step S3 through the IXCOM compilation tool based on Cadence, the compiled first part 200 generated by comprehensive compilation is added with -z1, -ua+1xua, -dpi, -timescale, etc. Compile with the compilation option, and also call Cadence's vxe and other first assembly tools to deconstruct the entire verification system 1000 (for example, assemble natural language programming into machine language) and other processes to generate hardware that can be directly used to simulate the verification device 100 information library to complete accelerator compilation.
  • Cadence's vxe and other first assembly tools to deconstruct the entire verification system 1000 (for example, assemble natural language programming into machine language) and other processes to generate hardware that can be directly used to simulate the verification device 100 information library to complete accelerator compilation.
  • the behavior modeling language may be a CPP language, that is, step S4 is used to compile the CPP code for the second part 300.
  • step S4 mainly compiles the CPP code of the test case set by the user, which may include: setting the type of the first function and/or the second function to be specifically called, how to match the first function and/or the second function to be called, The specific settings of the first function and/or the second function (such as register read and write addresses and specific written data) and the first reference file used for comparison (see below for details), etc.
  • the verification system calls the static library file generated by step S4 during the final run, so that the test cases set by the user can take effect and complete the test function during the simulation acceleration verification process.
  • the verification method of the present disclosure also includes the following process or step: verifying whether the above-mentioned register configuring the module under test meets the target requirements of the module under test 231 .
  • test case module 340 of the embodiment of the present disclosure provides different test cases, and the same module 231 to be tested can also develop multiple different test cases based on multiple different verification requirements. Different test cases will correspond to different function settings, register settings, expected data results, etc., thus different data will be written to the registers for the AMBA bus.
  • the first part 200 and the second part 300 created on the simulation verification device 100 in the embodiment of the present disclosure represent a verification environment built based on the simulation verification device 100.
  • the verification environment is divided into hardware side and software side, and the hardware side and software side can interact with each other.
  • the first part 200 is transplanted on the simulation verification device 100 such as the Palladium device, and the first part is located on other devices such as servers that can achieve connection and communication with the hardware side.
  • the first part 200 and the second part 300 run together on, for example, a Palladium device, and the embodiments of the present disclosure are not limited to this.
  • FIG. 6 is a flow chart of an execution process of step S5 of the verification method in FIG. 5 .
  • step S5 includes at least steps S51 to S53.
  • Step S51 In response to the module under test 231 being the first module, read the first data of the storage unit 221 through backdoor access to obtain the first reference file.
  • Step S52 In response to the module under test 231 being the second module, read the second data of the storage unit 222 through backdoor access to obtain the second file.
  • Step S53 Compare the second file with the first reference file to obtain the verification result.
  • reading the first data of the storage unit 221 through backdoor access to obtain the first reference file includes the following processes or steps: in response to the end of the test case running (for example, after the initial running of the test case ends), by The backdoor accesses and reads the first data of the storage unit 221 to obtain a self-named first target hexadecimal format file; and generates a standard version of the second target hexadecimal format file based on the first target hexadecimal format file. , obtain the first reference document.
  • the first target hexadecimal format file is the first hex file
  • the second target hexadecimal format file is the golden version of the second hex file.
  • the second module is configured as a module for updating based on the first module.
  • the second module is a module to be tested that is continuously iteratively updated based on the first module during the development of the chip. Therefore, every time the RTL code changes in the module to be tested 231 and iteratively updated, the test case needs to be re-run to test whether the RTL function has changed and to use the first reference file to calibrate the RTL.
  • reading the second data of the storage unit 221 through backdoor access to obtain the second file includes the following processes or steps: running the test case again, and reading the second data of the storage unit 221 through backdoor access, Get the second file.
  • the test case in step S52 is theoretically expected to be the same as the test case run for the first time in step S51, so that it can be determined whether the verification is passed.
  • step S53 the second file is compared with the first reference file, and obtaining the verification result includes the following processes or steps: If the comparison result of the second file and the first reference file is the same, the verification is passed and printing can be performed. For example, "testcase pass” characters or patterns are sent to the graphical interface, and the process ends; if the comparison results between the second file and the first reference file are different, the verification fails. For example, "testcase fail" characters or patterns can be printed to the graphical interface.
  • the test cases can be debugged and the RTL code of the module under test 231 can also be checked. Therefore, after modification and debugging, run it again and repeat the comparison process until the comparison results are the same, then the verification is passed and the process ends.
  • reading the second data of the storage unit 221 through backdoor access in step S52 to obtain the second file also includes the following processes or steps: Perform debugging, run the test case after debugging, read the second data of the storage unit 221 through backdoor access, and obtain the second file.
  • the test cases after debugging in step S52 are test cases with the same test case configuration compared to the test cases run for the first time in step S51. This can avoid the problem of verification failure due to errors in the test cases during the actual process. , thereby making the simulation verification process proceed smoothly.
  • test case may also be debugged, and embodiments of the present disclosure do not limit this.
  • the verification files and basic verification processes of the embodiments of the present disclosure are universal, which is beneficial to reducing the workload of verification.
  • the number of verification use cases is increasing, the complexity of verification use cases is also increasing, and the design is constantly iterating. Through automated regression testing, it helps to ensure project quality and reduce tedious tasks. workload.
  • Figure 7 is a flow chart of a verification method provided by other embodiments of the present disclosure.
  • the verification method provided by some embodiments of the present disclosure includes steps T1 to T8.
  • Step T1 The test case is run for the first time.
  • Step T2 Read the first data of the storage unit through backdoor access to obtain the first reference file.
  • Step T3 Run the test case again.
  • Step T4 Read the second data of the storage unit through backdoor access to obtain the second file.
  • Step T5 Compare the data of the second file with the data of the first reference file.
  • Step T6 Determine whether the data of the second file is the same as the data of the first reference file: if so, go to step T8; if not, the verification fails, and the debugging of the test case and the RTL of the module under test in step T7 are performed. Verify and execute step T3 to step T6 in a loop until the judgment results are the same, then go to step T8.
  • Step T8 The verification is passed and the verification process ends.
  • the first reference file in step T2 is the second hex file of the golden version.
  • test case in step T3 may be debugged after the verification fails.
  • the subsequent test cases may also be test cases obtained by debugging the test cases before starting step T3, and the embodiments of the present disclosure do not limit this.
  • the embodiments of the present disclosure can implement an automated process with certain universality, thereby realizing a simple, efficient, and highly reusable hardware acceleration test method and process, which greatly saves the time of the chip verification project. Greatly improves chip verification efficiency.
  • FIG. 8 is a schematic structural diagram of an electronic device according to at least one embodiment of the present disclosure.
  • the electronic device 400 includes a processing module 410 and a memory 420.
  • the memory 420 stores a computer program.
  • Verification methods of at least some embodiments of the present disclosure are implemented.
  • Electronic devices in embodiments of the present disclosure may include, but are not limited to, mobile terminals such as laptop computers, tablet computers, etc., and fixed terminals such as desktop computers, conventional servers, cloud servers, etc.
  • mobile terminals such as laptop computers, tablet computers, etc.
  • fixed terminals such as desktop computers, conventional servers, cloud servers, etc.
  • the electronic device shown in FIG. 8 is only an example and should not impose any limitations on the functions and scope of use of the embodiments of the present disclosure.
  • embodiments of the present disclosure may be implemented as a computer software program.
  • embodiments of the present disclosure include a computer program product including a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the method illustrated in the flowchart.
  • the computer program is executed by the processing module, the verification method of the embodiment of the present disclosure is executed.
  • the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two.
  • the computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples of computer readable storage media may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard drive, random access memory (RAM), read only memory (ROM), removable Programmd read-only memory (EPROM or flash memory), fiber optics, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above.
  • a computer-readable storage medium may be any tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device.
  • the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, in which computer-readable program code is carried. This propagated data signal can use many form, including but not limited to electromagnetic signals, optical signals or any suitable combination of the above.
  • a computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device .
  • Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wire, optical cable, RF (radio frequency), etc., or any suitable combination of the above.
  • the above-mentioned computer-readable medium may be included in the above-mentioned electronic device; it may also exist independently without being assembled into the electronic device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

本公开提供一种验证系统、验证方法、电子设备以及存储介质。验证系统包括仿真验证设备、第一部分和第二部分。第一部分包括第一主模块和第二从模块。第二从模块包括与待测模块外围的访存接口连接的存储单元。第二部分包括第一、第二直接编程接口、函数库模块和用于提供测试用例的测试用例模块。第一直接编程接口与第一主模块通信且配置为：响应于运行测试用例，调用函数库模块的第一函数以实现待测模块的寄存器的前门访问。第二直接编程接口与存储单元通信且配置为：响应于运行测试用例，调用函数库模块的第二函数以实现存储单元的后门访问。该验证系统实现软件侧与硬件侧的同步，方便待测模块的功能验证，仿真消耗时间少，实现芯片可重用验证。

Description

验证系统、验证方法、电子设备以及存储介质
本申请要求于2022年8月31日递交的中国专利申请第202211062729.2号的优先权，在此全文引用上述中国专利申请公开的内容以作为本申请的一部分。
技术领域
本公开的实施例涉及一种验证系统、验证方法、电子设备以及存储介质。
背景技术
目前，随着电子信息产业的急速发展，片上系统芯片(System On Chip，SoC)规模越来越大，平均占整个芯片开发工作量接近70％的芯片验证工作也越来越复杂，对芯片风险控制的要求也越来越高。
超大规模(Very Large Scale Integration，VLSI)集成电路芯片伴生的集成电路硬件模型随之变得非常复杂，与之对应的设计与验证计算量也大大增加。因此，对于复杂度较高的功能测试场景，电子设计自动化(Electronic Design Automation，EDA)仿真的速度、容量与效率已经很难满足SoC验证的需要，硬件加速验证技术便应运而成。
硬件加速验证技术通过硬件模拟器来对芯片设计进行验证，它将待测设计(Design Under Test，DUT)映射到处理器阵列或现场可编程门阵列(Field Programmable Gate Array，FPGA)上，然后对映射的等效系统进行验证。
硬件加速验证手段的速度相比软件仿真有着质的提升。软件仿真速率平均为例如1KHz，而硬件加速仿真验证方法则平均能达到例如2MHz，大大提高验证效率。
发明内容
本公开至少一实施例提供了一种验证系统，包括仿真验证设备以及分别创建在所述仿真验证设备上的第一部分和第二部分，其中，所述第一部分包括分别与待测对象连接的第一主模块和至少一个第二从模块；所述待测对象 包括待测模块和连接在所述待测模块的外围的多个对象接口，所述多个对象接口包括访存接口，所述第二从模块包括存储单元，所述存储单元与所述访存接口连接；所述第二部分包括第一直接编程接口、第二直接编程接口、函数库模块和测试用例模块，所述测试用例模块配置为提供至少一个测试用例；所述第一直接编程接口与所述第一主模块通信，且所述第一直接编程接口配置为：响应于运行所述测试用例，调用所述函数库模块中的至少一个第一函数，以实现所述待测模块的寄存器的前门访问；所述第二直接编程接口与所述第一部分的所述存储单元通信，且所述第二直接编程接口配置为：响应于运行所述测试用例，调用所述函数库模块中的至少一个第二函数，以实现所述存储单元的后门访问。
本公开至少一实施例还提供一种基于如上文所述的验证系统的验证方法，包括：基于所述待测模块进行寄存器传输级代码编译；基于所述第一部分、所述待测对象、所述待测模块、所述第一主模块和所述第二从模块进行综合编译，获取已编译的所述第一部分；选择所述仿真验证设备的使用模式，根据所述使用模式，将已编译的所述第一部分加入至少一个编译选项，并调用第一汇编工具对所述验证系统进行解构，生成用于所述仿真验证设备的硬件信息库，以实现加速器编译；对所述第二部分进行行为建模语言的代码编译；运行已编译的所述第一部分和所述第二部分，获取验证结果。
本公开至少一实施例提供了一种电子设备，包括：处理模块和存储器，其中，所述存储器上存储有计算机程序，所述计算机程序被所述处理模块执行时，实现如上文任一项所述的验证方法。
本公开至少一实施例提供了一种计算机可读存储介质，其中，所述存储介质内存储有计算机程序，所述计算机程序被处理模块执行时，实现如上述任一示例中所述的验证方法。
附图说明
为了更清楚地说明本公开实施例，下面将对实施例所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本公开一些实施例提供的一种验证系统的框图示意图；
图2为本公开一些实施例提供的验证系统的软件侧的框图示意图；
图3本公开一些实施例提供的验证系统的第一主模块的框图示意图；
图4为本公开一些实施例提供的第一主模块和第二从模块的地址空间的示意图；
图5为本公开一些实施例提供的一种验证方法的流程图；
图6是图5中的验证方法的步骤S5的一种执行过程的流程图；
图7为本公开另一些实施例提供的一种验证方法的流程图；以及
图8为本公开一些实施例提供的一种电子设备的框图。
具体实施方式
下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
除非另有定义，本公开实施例使用的所有术语(包括技术和科学术语)具有与本公开所属领域的普通技术人员共同理解的相同含义。还应当理解，诸如在通常字典里定义的那些术语应当被解释为具有与它们在相关技术的上下文中的含义相一致的含义，而不应用理想化或极度形式化的意义来解释，除非本公开实施例明确地这样定义。
本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“一个”、“一”或者“该”等类似词语也不表示数量限制，而是表示存在至少一个。同样，“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的，而且“连接”或者“相连”等类似的词语也包括通信连接。
本公开实施例中使用了流程图用来说明根据本公开实施例的方法的步骤。应当理解的是，前面或后面的步骤不一定按照顺序来精确的进行。相反， 可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步。
本公开的研究发现，硬件仿真加速验证平台，包括基于FPGA的验证平台，基于FPGA的验证平台包括HAPS或ZEBU等。但是基于FPGA的验证平台由于容量限制、综合耗时长、调试困难、需要手动划分大系统以及需要修改时钟树等特性的限制，使得基于FPGA的验证平台不适合做替代EDA仿真的功能仿真加速。
本公开的研究还发现，目前一些仿真加速的方案具有以下的缺点：
第一，基于通用验证方法学(Universal Verification Methodology，UVM)的仿真加速，虽然在做仿真加速时能复用原本的UVM环境和测试用例，但是UVM相关方法学的外壳解析起来较为复杂，加速性能偏低，而且UVM迁移到可综合的仿真加速验证平台上需要做大量优化工作，耗时耗力。
第二，基于嵌入式接口的仿真加速虽然速度较快，但需要将测试平台写成可综合的形式并综合到仿真加速器中，重用性很低，不同的测试平台与仿真加速器结合时都需重新改写、解析和调试，工作量较大。
本公开至少一实施例提供了一种验证系统，包括仿真验证设备以及分别创建在仿真验证设备上的第一部分和第二部分；第一部分包括分别与待测对象连接的第一主模块和至少一个第二从模块；待测对象包括待测模块和连接在待测模块的外围的多个对象接口，多个对象接口包括访存接口，第二从模块包括存储单元，存储单元与访存接口连接；第二部分包括第一直接编程接口、第二直接编程接口、函数库模块和测试用例模块，测试用例模块配置为提供至少一个测试用例；第一直接编程接口与第一主模块通信，且第一直接编程接口配置为：响应于运行测试用例，调用函数库模块中的至少一个第一函数，以实现待测模块的寄存器的前门访问；第二直接编程接口与第一部分的存储单元通信，且第二直接编程接口配置为：响应于运行测试用例，调用函数库模块中的至少一个第二函数，以实现存储单元的后门访问。
本公开上述实施例的验证系统通过提供第一直接编程接口和第二直接编程接口，可以实现验证系统的软件侧与硬件侧的同步，方便在待测模块的功能验证中实现寄存器读写、存储单元访存等操作，仿真消耗时间少，芯片验证效率提升，能够实现芯片的系统级和/或模块级的可重用的验证，应用前 景广泛。
图1为本公开一些实施例提供的一种验证系统的框图示意图。图2为本公开一些实施例提供的验证系统的软件侧的框图示意图。
例如，如图1所示，验证系统1000包括仿真验证设备100以及分别创建在仿真验证设备100上的第一部分200和第二部分300。例如，第一部分200为硬件侧，该硬件侧配置为基于硬件描述(HDL)语言创建。第二部分300为软件侧，该软件侧配置为基于行为建模语言创建。例如，硬件描述语言包括Verilog、SystemVerilog等，行为建模语言包括C语言或CPP语言(也可称之为C++语言)等。
例如，如图1所示，第一部分200包括分别与待测对象230连接的第一主模块210和至少一个第二从模块220。待测对象230包括待测模块231和连接在待测模块231的外围的多个对象接口。多个对象接口包括至少一个访存接口232。第二从模块220包括存储单元221，存储单元221与访存接口232连接。
例如，待测模块231即为待测设计(Design Under Test，DUT)，例如，DUT通过RTL(Register Transfer Level，寄存器传输级)设计代码实现。
例如，如图1所示，第二部分300包括第一直接编程接口310、第二直接编程接口320、函数库模块330和测试用例模块340。测试用例模块340配置为提供至少一个测试用例。
例如，第一直接编程接口310和/第二直接编程接口320均为直接编程语言接口DPI(Direct Programming Interface)，其是用于在硬件描述语言(例如SystemVerilog)和用于软件的编程语言(例如C/C++)之间相互调用的接口。
例如，函数库模块330配置为基于多个函数制作形成的函数库，以供其他程序使用，例如，函数库模块330可以选用静态库。函数库模块330的内部包括至少一个第一函数和至少一个第二函数，其中，第一函数在被调用使用时可实现寄存器的配置，第二函数在被调用使用时可实现存储单元的访存。
例如，如图1所示，第一直接编程接口310与第一主模块210通信，且第一直接编程接口310配置为：响应于运行源于测试用例模块340的测试用例，调用函数库模块330中的至少一个第一函数，以实现待测模块231的寄存器的前门访问。例如，前门访问包括前门读数据操作和/或前门写数据操作， 对应地，第一函数包括关于寄存器读和/或写的函数。
例如，如图1所示，第二直接编程接口320与第一部分200的存储单元221通信，且第二直接编程接口320配置为：响应于运行源于测试用例模块340的测试用例，调用函数库模块330中的至少一个第二函数，以实现存储单元221的后门访问。例如，后门访问包括后门数据加载操作和/或后门数据导出操作，对应地，第二函数包括存储单元加载和/或导出函数。
在一些示例中，本公开的实施例的“前门访问”是指通过寄存器配置总线(例如AMBA协议)模拟CPU(中央处理器，Central Processing Unit)在总线上发出读写指令，遵循总线时序对DUT的寄存器实际值进行读写访问。前门访问涉及真实的RTL传输且前门访问依赖于总线时序协议进行传输，因此，前门访问会消耗仿真时间。例如，前门访问不可按域读写。
在一些示例中，本公开的实施例的“后门访问”是指直接读取存储单元的二维数组的访问方式。后门访问不消耗仿真时间。例如，后门访问可按域读写。
本公开上述实施例的验证系统通过提供第一直接编程接口和第二直接编程接口，可以实现验证系统的软件侧与硬件侧的同步，方便在待测模块的功能验证中实现寄存器读写、存储单元访问等，仿真消耗时间少，芯片功能的验证效率提升，能够实现芯片的系统级和模块级的可重用的验证，应用前景广泛。
在一些示例中，第一部分200的待测对象230是验证系统100的硬件侧的顶层，例如，待测对象230的待测模块231包括SoC芯片的IP(Intellectual Property)模块。例如，待测模块231可以是验证系统100待进行验证的SOC中的一个独立IP。例如，该SOC可以基于X86、ARM、RISC-V等指令集的微架构，本公开的实施例对此不作限制。待测模块231具有普适性，适用于芯片中的关键IP，例如待测模块23包含但不限于GPGPU(通用图形处理器)，本公开的实施例在此不做限制和赘述。本公开上述实施例的验证系统可适用于SoC中IP级别模块的仿真验证加速和软件bare metal开发，仿真验证所需的时间大大减少。
还需要说明的是，本公开的实施例的待测模块231在一些场景下可以属于IP模块级别，还可以在其他一些场景下属于子系统级别，本公开的实施例 对此不作限制，并且这也并不影响本公开的保护范围。
需要说明的是，本公开的实施例的第一主模块和第二从模块分别是相对于待测对象而言而被称之为是主模块或从模块，此仅仅为是一种命名方式，便于本公开的描述的清楚与简洁，本公开的实施例不限于此，本公开的实施例的保护范围也不受此限制。
在一些示例中，仿真验证设备100包括第一处理器且第一处理器包括并行连接的多个第二处理器，即第二处理器相对于第一处理器为子处理器。
例如，仿真验证设备包括Cadence的Palladium设备，Palladium设备的底层架构为CPU处理器和专用集成电路。Palladium设备的处理器是大量的处理器并行连接的，从而可以通过并行通路进行仿真验证加速。
本公开的实施例基于例如Palladium设备的仿真验证设备进行硬件仿真加速验证，能够使得芯片RTL保持兼容，改动较少；调试性能优异，信号可见性高；平台兼容性高，可支持SystemVerilog或System C或System CPP；而且无需手动划分SoC设计，不需太多额外人力投入等，从而可以很好地满足芯片项目对验证时间的要求和芯片交付质量。
需要说明的是，本公开的实施例的验证系统采用的仿真验证设备不仅限于Palladium设备，还可以是其他基于处理器构建的仿真验证设备，本公开的实施例不作限制和赘述。
在一些示例中，第二部分300配置为基于C语言或CPP语言创建，例如，第二部分300为运行在Cadence的例如编译软件Xcelium上的软件侧。这样本公开的实施例的验证系统可以方便地在将C语言或CPP语言代码编译之后实现相关指令的执行，应用广泛，方便研发人员的开发工作。
在一些示例中，第一主模块210用于生成读和/或写指令并配置待测模块231的寄存器以及产生复位，例如全局复位。例如，如图1和图2所示，第二部分200还包括驱动模块350，用于驱动第一部分200的第一主模块210，使得第一主模块210配置待测模块231的寄存器并进行全局复位。
在一些示例中，第一主模块210和第二从模块220是在验证单元组件(Verification IP，VIP)的基础上且针对仿真验证设备100设计的AVIP(Accelerated Verification IP)。
例如，如图2所示，第一主模块210包括高级微处理器总线架构式的主 模块，也可称之为AMBA MASTER，即第一主模块210支持AMBA标准总线协议。对应地，驱动模块350也可称之为AMBA MASTER Driver。例如，第二从模块220包括高级微处理器总线架构式的从模块，也可称之为AMBA SLAVE，即第二从模块220支持AMBA标准总线协议。
本公开上述实施例的验证系统通过采用可支持多种标准总线协议的AVIP使得能够实现模块级和子系统级更广泛的总线协议验证。
例如，如图1所示，第一部分200还包括时钟激励源模块240，时钟激励源模块240用于提供硬件侧的系统时钟信号，以供DUT等使用。例如，时钟信号的时钟频率可以为1GHZ。此仅仅为示例性的，并不为本公开的限制。
例如，如图1所示，待测对象230的多个对象接口还包括第一接口233a、第二接口233b、第三接口233c、第四接口233d中的至少一个。
例如，如图1所示，第一接口233a与时钟激励源模块240连接，以接收时钟信号。本公开的验证系统可以由一个全局时钟驱动，这有利于同步数字系统的功能、性能和稳定性。
例如，如图1所示，第二接口233b配置为接收中断请求信号。例如，中断请求信号用于停止相关硬件当前的工作状态而切换到对中断请求信号对应的操作任务，并且在该操作任务处理完成之后再切换回来，从而可以避免引起信号冲突。
例如，如图1所示，第一主模块210与第三接口233c连接，以用于配置待测模块231的寄存器。例如，如图1所示，第一主模块210与第四接口233d连接，以用于复位第一部分200。
例如，在图1的示例中，访存接口232的数目为两个，第二从模块220的数目为两个，每个第二从模块220均包括一个存储单元221。如此，存储单元221与访存接口232一一对应，这样可以形成每个存储单元221与待测模块231之间的数据传输通路，从而可以实现寄存器前门访问。此仅仅为示例性的，并不为本公开的限制。
例如，如图1所示，第二从模块220的存储单元221用于存储寄存器数据，即第二从模块220在验证系统100中的主要作用是作为验证系统的存储器。例如，对于实现前门写操作，本公开的实施例通过访存接口232，可实 现将通过前门写操作而写入的数据存储到存储单元221中。
例如，如图1所示，如果需要，第一部分200还可以包括速率匹配桥250，速率匹配桥250配置为分别与第二从模块220以及访存接口232连接。本公开的实施例通过速率匹配桥250可以进行读写速率的转换与处理，从而可以避免待测模块231与存储单元221之间的跨时钟域的数据传输的亚稳态以及时钟信号不匹配等问题。
在一些示例中，第二从模块220的存储单元221中的数据的来源包括两种。第一种是通过前门写操作将数据写进待测模块231的寄存器并且经由速率匹配桥250跨时钟域传入第二从模块220的存储单元221。第二种是通过后门的数据加载操作将数据导入存储单元221。
在一些示例中，第二从模块220的存储单元221具有虚拟的存储空间。例如，本公开可以通过Palladium设备来划分一部分存储空间给到存储单元221。此仅仅为示例性的，并不为对本公开实施例的限制。
例如，如图2所示，第一直接编程接口310包括基于C语言或CPP语言的直接编程接口(C/C++DPI)，第二直接编程接口320包括基于C语言或CPP语言的一次性访问型的直接编程接口(MARG DPI)。例如，MARG DPI为一种类型的接口，相对更适用于一次性的存储和读取。
本公开的实施例通过DPI接口连接验证系统的软件侧和硬件侧，这样不仅可以通过DPI的CPP接口函数使得第一主模块210能够完成例如AMBA总线的寄存器的前门访问(例如前门读写操作)，而且还能基于设置的MARG DPI，使得第二从模块220的存储单元221通过调用MARG DPI对应的CPP接口函数，可以直接实现存储单元221的后门访问，从而可实现存储单元的数据加载和数据导出。
本公开的实施例采用的CPP接口函数(例如上文所述的第一函数或第二函数，例如第一函数可以包括关于寄存器读和/或写的函数，第二函数包括存储单元加载和/或导出函数等)经CPP语言的编写、包装，方便调用，可以实现函数更复杂的功能，功能更贴合芯片需求的测试用例，并且实现了软件侧与硬件侧的同步，仿真加速的效率大大提高。
图3本公开一些实施例提供的验证系统的第一主模块的框图示意图。
例如，如图3所示，第一主模块210包括主核211和第三从模块212。 例如，第三从模块212嵌入至第一主模块210中，第三从模块212为嵌入式高级外围总线从模块，即嵌入式APB模块。需要说明的是，本公开的实施例的第三从模块212是相对于主核211而言被称之为一种从模块，此仅仅为是一种命名方式，本公开的实施例不限于此，本公开的实施例的保护范围也不受此限制。
在一些示例中，第一主模块210的主核211为AVIP核，第一主模块210的主核211包括可综合的RTL代码。
例如，如图3所示，主核211分别与第一直接编程接口310和第三接口233c连接，使得主核211获取对应于测试用例的第一函数的寄存器访存指令(即用于对待测模块231的寄存器进行读操作或写操作的指令)，以用于配置待测模块231的寄存器。
例如，在用户运行测试用例并调用第一函数时，第一主模块210的主核211会获取寄存器访存指令，以用于配置待测模块231的寄存器。
在一些示例中，主核211还会获取与寄存器访存指令相关的控制数据。控制数据包括对寄存器进行读操作或写操作时所需的基础数据，例如内存的基地址和内存的基础宽度等。此仅仅为示例性的，并不为本公开的限制。
例如，如图3所示，第一主模块210的第三从模块212分别连接主核211和第四接口233d，这样可将主核211产生的复位信号传输至第四接口233d，以用于复位第一部分200。例如，在每个测试用例开始运行进行仿真之前需要进行复位，以使得硬件侧内部所有的核的状态和所有内存的状态都是最初始的状态。
在一些示例中，第二从模块220为AMBA模块时，可以例化成多个不同类型的AMBA模块，例如可以是APB模块或AXI模块或ACE模块。此仅仅为示例性的，并不为本公开的限制。
在一些示例中，在例化第二从模块220时，需要声明的AMBA参数包括以下的至少一种：内存大小、内存基地址以及可以支持的当前正在进行的(Outstanding)操作的深度。此仅仅为示例性的，并不为本公开的限制。
在一些示例中，第一主模块210、第二从模块220和第三从模块212分别被配置独立的存储空间。例如，在验证系统1000完成初步搭建后，需要向例如第一主模块210、第二从模块220和第三从模块212等各个模块分配存 储空间。
图4为本公开一些实施例提供的第一主模块和第二从模块的地址空间的示意图。
在一些示例中，第一主模块210的地址偏移为0x0000_0000，第三从模块212的地址偏移为0x0010_0000(1M Byte)。例如，如图4所示，第一主模块210的地址范围包括0x0000_0000～0x000F_FFFF且大小为1MB以及0x0010_0000～0x001F_FFFF且大小为1MB。例如，如图4所示，两个第二从模块220中的一个第二从模块220的地址范围是0x4000_0000～0x7FFF_FFFF且大小为1GB，另外一个第二从模块220的地址范围是0x8000_0000～0xFFFF_FFFF且大小为2GB。此仅仅为示例性的，并不为本公开的限制。
在一些示例中，第二部分300还包括配置文件。测试用例配置为基于配置文件的至少一个第一函数进行用例配置，以进行前门访问，或者，测试用例配置为基于配置文件的至少一个第二函数进行用例配置，以进行后门访问。
在一些示例中，函数库模块330包括基于测试用例和配置文件并通过行为建模语言编译生成的静态库。
例如，在图2的示例中，测试用例模块340提供的测试用例包括test0～test3，不同测试用例会调用不同的函数以验证符合需求的功能。例如，如图2所示，对于测试用例模块340，其可以通过使用test_entry()来调用配置文件以提供相关测试用例。test_entry()是用户编辑待测的测试用例的入口，test_entry()中会调用配置文件(例如.cfg文件)以完成相关测试用例的配置。验证系统1000可以为用户提供API用来配置寄存器的前门访问和后门访存，例如，配置文件经C/CPP编译生成静态库user lib，由API接口进一步解析，完成例如对寄存器的读写。
本公开上述实施例的仿真加速验证使用基于C/CPP代码构建的测试用例，使得环境相对比较简单，没有复杂方法学，可以快速地搭建好仿真环境，并且运行速度非常快。
在一些示例中，第一函数包括：寄存器读函数reg_read、寄存器写函数reg_write、寄存器读后检查函数reg_read_check、寄存器写后读并检查函数reg_write_check、寄存器轮询唤醒读函数poll_reg_equal中的至少一个。
例如，函数reg_write用于直接实现在特定寄存器地址写入32bit数据，函数reg_read用于直接实现读出特定寄存器地址的32bit数据。
例如，函数reg_read_check用于检查特定地址寄存器写入的数据是否与预期相同，例如特定地址寄存器写入的数据可以是通过函数reg_write写入的数据。
例如，函数reg_read_check先从特定地址寄存器读取数据，然后将读取出的数据与预期数据相比较，如果比较结果为相同，则检查通过，若比较结果为不相同，则会停止当前操作并报错。本公开的实施例通过函数reg_read_check可将数据写入特定地址的寄存器，并自动将读数结果与预期结果相比较，这样自动化程度比较高，能提高验证人员的工作效率。
函数reg_write_check的作用和方法也可参照函数reg_read_check，区别在于函数reg_write_check还包括在特定地址寄存器写入数据，此处不再赘述。
例如，函数poll_reg_equal用于对特定地址寄存器进行连续多次轮询和读取数值，直到从特定地址寄存器读取到的数值与预期数值相等；若不相等则继续读取，直到读取次数超出用户所设置的最大轮询次数(例如为10000)，报错并结束轮询；若从同一地址寄存器读取多次数值但依然与预期数值不等，则报错，结束读数循环。
例如，函数poll_reg_equal可以在第二函数对第二从模块的存储单元进行后门访问之前，部分寄存器需要进行轮询操作以唤醒寄存器的情况下，对相关的寄存器进行轮询唤醒并依次核对寄存器数据的读写结果。
在一些示例中，第二函数包括：存储单元轮询唤醒读函数poll_mem_equal、存储单元初始化函数mem_init、存储单元数据加载函数mem_load、存储单元数据导出函数中的至少一个。
在一些示例中，存储单元数据导出函数包括存储单元多字节读函数或存储单元数据抓取函数mem_dump，其中，函数mem_dump和存储单元多字节读函数读出的数据段长度不同，函数mem_dump读出的数据段长度大于存储单元多字节读函数读出的数据段长度。
例如，存储单元多字节读函数包括函数mem_read32或函数mem_read64。函数mem_read32用于直接实现读出特定存储单元地址的32bit数据，函数mem_read64用于直接实现读出特定存储单元地址的64bit数据。
例如，函数mem_dump可从存储单元中抓取数据，将存储单元中的数据以十六进制格式抓取到自命名的十六进制格式文件(hex文件)中。
例如，函数mem_load将格式为十六进制格式的可读文件加载进验证系统中。此十六进制格式文件是一个二维数组，前为地址，后为数据，函数mem_load函数依据每个数据的地址，将其加载进对应的存储空间。
例如，函数poll_mem_equal用于对指定地址的存储单元进行连续多次轮询和读取数值，直到从特定地址的存储单元读取到的数值与预期数值相等；若比较结果为不相等，则继续读取，直到读取次数超出用户所设置的最大轮询次数(例如为10000)，报错并结束轮询；若从同一地址的存储单元读取多次数值但依然与预期数值不等，则报错，结束读数循环。
例如，函数mem_init用于对使用到的地址范围内的存储单元进行初始化，防止上一次运行测试用例后，存储单元残留的数据影响下一次测试用例的运行和结果比对。函数mem_init对已设定地址范围的存储单元进行初始化，主要有五种模式：
模式0：存储单元的数值全部初始化为0x0000_0000；
模式1：存储单元的数值全部初始化为0xFFFF_FFFF；
模式2：存储单元的数值初始化为每个存储单元地址的数值；
模式3：存储单元的数值初始化为从0x0开始每次递增0x4的数值；
模式4：存储单元的数值初始化为从0开始每次递增1的数值。
上述模式以及对应的功能仅仅为示例性的，并不为对本公开的实施例的限制。
在一些示例中，函数库模块330还可包括文件比对函数file_cmp和/或复位函数glb_rst。
例如，函数file_cmp可以对两个hex文件进行比对，用以获取对比结果。在本公开的实施例的测试用例中，用户可以在file_cmp函数定义中，自行指定需要进行比对操作的两个hex文件的名称。
例如，函数glb_rst可以复位第一部分200，重置第一部分200中的模块状态。
在一些示例中，测试用例模块340提供的多个测试用例中的每个测试用例可以不完全相同，各个测试用例对应的函数可以是一个或多个，例如各个 测试用例可以是上文描述的任一函数或多个函数的任意组合，本公开的实施例对此不作限制，其可以根据实际验证需要进行自由的调整，此处不再赘述。
需要说明的是，本公开的实施例的函数库模块330包括的函数不仅限于上述示例，还可以是其他的用于满足验证需求的对应函数，这里不再穷举和赘述。
本公开至少一实施例还提供了一种验证方法，该验证方法可以基于上述任一实施例所述的验证系统实现。关于基于验证系统的验证方法的具体实施方式和技术效果可以参考本公开上述实施例中提供的验证系统。
图5为本公开一些实施例提供的一种验证方法的流程图。
例如，如图5所示，本公开至少一实施例提供的一种验证方法包括步骤S1至步骤S5。
步骤S1、基于待测模块231进行RTL代码编译。
步骤S2、基于第一部分200、待测对象230、待测模块231、第一主模块210、第二从模块220进行综合编译，获取已编译的第一部分200。
步骤S3、选择仿真验证设备100的使用模式，根据使用模式将已编译的第一部分200加入至少一个编译选项，并调用第一汇编工具对验证系统1000进行解构，生成用于仿真验证设备100的硬件信息库，以实现加速器编译。
步骤S4、对第二部分300进行行为建模语言的代码编译。
步骤S5、运行已编译的第一部分200和第二部分300，获取验证结果。
在一些示例中，本公开的验证方法还包括以下过程或步骤：根据验证结果进行调试，以使得验证通过。
在一些示例中，本公开的验证方法还包括以下过程或步骤：将验证结果配置为在仿真验证设备100上可视化，可视化方式包括但不限于图表、文本、波形图等。这样可以及时、方便且准确地反映验证结果，有利于验证工作的管理和执行。
例如，在步骤S1中，基于待测模块231进行RTL代码编译，包括以下过程或步骤：使用第二编译工具编译待测模块231的RTL文件列表及对应RTL文件，生成包含待测对象230的设定格式的DUT网表，例如生成包含待测对象230的vg格式的DUT网表。该生成的DUT网表配置为在仿真验证设备100上运行。需要说明的是，本公开的实施例的DUT网表的设定格 式不仅限于vg格式，还可以是其他类型的格式，例如edif格式等，本公开的实施例对此不作限制。
例如，在步骤S1中，第二编译工具包括Cadence的编译工具vavlog或编译工具vaelab。当然，此仅仅为示例性的，并不为本公开的限制。
例如，在步骤S2中，基于第一部分200、待测对象230、待测模块231、第一主模块210和第二从模块220进行综合编译，获取已编译的第一部分200，包括以下过程或步骤：基于仿真验证设备100的第三编译工具对第一部分200、待测对象230、待测模块231、第一主模块210、第二从模块220(例如图1中的两个第二从模块220)和时钟激励源模块240进行综合编译，获取已编译的硬件侧。
例如，第三编译工具包括Cadence基于Palladium的vlan工具。当然，此仅仅为示例性的，并不为本公开的限制。
例如，在步骤S2中，本公开的实施例的综合编译的对象不仅包括第一部分200、对待测对象230、待测模块231、第一主模块210和第二从模块220，还包括例如编译必需的Cadence AVIP文件以及其他所需外围测试资源进行综合编译，由于此不为本公开的实施例需要描述的重点，这里不再穷举和赘述。因此，通过该步的综合编译可以生成已编译的硬件侧。
例如，在步骤S3中，选择仿真验证设备100的使用模式，根据使用模式将已编译的第一部分200加入至少一个编译选项进行加速器编译，并调用第一汇编工具对验证系统进行解构，生成用于仿真验证设备的硬件信息库，包括以下过程或步骤：选择Palladium设备的IXCOM模式，根据IXCOM模式，将已编译的第一部分200加入至少一个编译选项，并调用第一汇编工具对验证系统1000进行解构，生成硬件信息库(hardware lib)。例如，硬件信息库包含RTL、仿真环境、编译环境等信息的lib库。此仅仅为示例性的，并不为本公开的限制。
本公开的实施例选用Palladium的IXCOM模式，这样使得对设计中不可综合的部分兼容性更高，支持将部分设计放到仿真验证设备中，同时兼容其他模式，可以减少验证的工作量，减少成本，提高验证效率。
例如，在步骤S3中，通过基于Cadence的IXCOM编译工具，将综合编译生成的已编译的第一部分200，加入例如-z1、-ua+1xua、-dpi、-timescale等 编译选项进行编译，并且还可调用Cadence的vxe等第一汇编工具，对验证系统1000整体进行解构(例如将自然语言编程汇编为机器语言)等处理，生成可直接用于仿真验证设备100的硬件信息库，从而完成加速器编译。此仅仅为示例性的，并不为本公开的限制。
例如，在步骤S4中，行为建模语言可以是CPP语言，即步骤S4用于对第二部分300进行CPP代码编译。
例如，步骤S4中主要编译用户设置的测试用例的CPP代码，例如可包括：设置具体调用的第一函数和/或第二函数的类型、调用的第一函数和/或第二函数如何搭配、第一函数和/或第二函数的具体设置(例如寄存器读写地址和具体写入的数据)和用于进行比对的第一参考文件(具体可见下文)等。由此，验证系统在最终运行时调用由该步骤S4生成的静态库的文件，从而使得用户设置的测试用例能在仿真加速验证过程中生效并完成测试功能。
在一些示例中，本公开的验证方法还包括以下过程或步骤：检验上述的配置待测模块的寄存器是否符合待测模块231的目标需求。
例如，对于不同的待测模块231，本公开的实施例的测试用例模块340提供的测试用例均有所不同，并且同一待测模块231也可基于多个不同的验证需求可开发出多个不同的测试用例，不同的测试用例会对应不同的函数设置、寄存器设置、预期数据结果等，由此会对针对AMBA总线的寄存器会进行不同的数据写入。
在一些示例中，对于本公开的实施例中的创建在仿真验证设备100上的第一部分200和第二部分300，其表示基于仿真验证设备100进行搭建的验证环境，验证环境分为硬件侧和软件侧，且硬件侧和软件侧可以彼此交互。例如，其可以是第一部分200移植在例如Palladium设备的仿真验证设备100上，且第一部分位于能够实现与硬件侧连接通讯的其他例如服务器的设备上。当然，其也可以是第一部分200和第二部分300共同运行在例如Palladium设备上，本公开的实施例对此不作限制。
图6是图5中的验证方法的步骤S5的一种执行过程的流程图。例如，如图6所示，步骤S5的一个示例至少包括步骤S51～步骤S53。
步骤S51、响应于待测模块231为第一模块，通过后门访问读取存储单元221的第一数据，以获取第一参考文件。
步骤S52、响应于待测模块231为第二模块，通过后门访问读取存储单元222的第二数据，以获取第二文件。
步骤S53、将第二文件与第一参考文件进行对比，获取验证结果。
例如，在步骤S51中，通过后门访问读取存储单元221的第一数据，以获取第一参考文件，包括以下过程或步骤：响应于测试用例运行结束(例如测试用例初次运行结束之后)，通过后门访问读取存储单元221的第一数据，得到自命名的第一目标十六进制格式文件；以及基于第一目标十六进制格式文件生成标准版本的第二目标十六进制格式文件，获取第一参考文件。
例如，第一目标十六进制格式文件即为第一hex文件，第二目标十六进制格式文件即为golden版本的第二hex文件。此仅仅为示例性的，并不为本公开的限制。
例如，在步骤S52中，第二模块配置为基于第一模块进行更新的模块。第二模块是在随着芯片开发的过程中，基于第一模块不断进行迭代更新的待测模块。因此，在待测模块231每次发生RTL代码的变化进行迭代更新时，需要重新运行测试用例，用以测试RTL功能是否变化并使用第一参考文件来校准RTL。
例如，在步骤S52中，通过后门访问读取存储单元221的第二数据，以获取第二文件，包括以下过程或步骤：再次运行测试用例，通过后门访问读取存储单元221的第二数据，获取第二文件。例如，该步骤S52中的测试用例理论上期望是与上述步骤S51中初次运行的测试用例相同，从而可以判断验证是否通过。
例如，在步骤S53中，将第二文件与第一参考文件进行对比，获取验证结果包括以下过程或步骤：若第二文件与第一参考文件的比对结果为相同，则验证通过，可以打印例如“testcase pass”字符或图案至图形界面，流程结束；若第二文件与第一参考文件的比对结果为不同，则验证未通过，可以打印例如“testcase fail”字符或图案至图形界面，并对测试用例进行调试，还可核对待测模块231的RTL代码。由此，修改调试后再重新运行，重复比对的过程，直至得到比对结果为相同，则验证通过，流程结束。
由此，在验证未通过的情况下，步骤S52中的通过后门访问读取存储单元221的第二数据，以获取第二文件，还包括以下过程或步骤：对测试用例 进行调试，运行调试之后的测试用例，通过后门访问读取存储单元221的第二数据，获取第二文件。例如，步骤S52中调试之后的测试用例相对于步骤S51中初次运行的测试用例来说，它们是进行相同用例配置的测试用例，这样可以避免因为实际过程中测试用例的错误而导致验证失败的问题，从而使得仿真验证流程的顺利进行。
在一些示例中，对于步骤S52，在再次运行测试用例之前，也可以对测试用例进行调试，本公开的实施例对此不作限制。
在一些示例中，在运行已编译的第一部分200和第二部分300时，可以通过执行Makefile中已经包装好的指令Make emu_run，直接启动Palladium设备的图形界面，如此，测试用例的运行结果及对应的必要日志信息会打印到图形界面上，以供使用者进行进一步的调试和结果记录。
本公开的实施例的验证文件和基础验证流程具有通用性，有利于减少验证的工作量。在随着验证工作的深入，验证用例的数量越来越多、验证用例的复杂度也在不断增加以及设计的不停迭代，通过自动化回归测试的工作，有助于确保项目质量，减少繁琐任务的工作量。
图7为本公开另一些实施例提供的验证方法的流程图。
例如，如图7所示，本公开一些实施例提供的验证方法包括步骤T1至步骤T8。
步骤T1、测试用例初次运行。
步骤T2、通过后门访问读取存储单元的第一数据，获取第一参考文件。
步骤T3、再次运行测试用例。
步骤T4、通过后门访问读取存储单元的第二数据，获取第二文件。
步骤T5、将第二文件的数据与第一参考文件的数据进行对比。
步骤T6、判断第二文件的数据与第一参考文件的数据是否相同：若是，则转至步骤T8；若否，则验证失败，并执行步骤T7中的测试用例的调试和待测模块的RTL核对，循环执行步骤T3至步骤T6，直至判断结果为相同，转至步骤T8。
步骤T8、验证通过，结束验证流程。
例如，步骤T2中的第一参考文件为golden版本的第二hex文件。
例如，步骤T3中的测试用例可以是在验证未通过的情况下而被调试之 后的测试用例，也可以是在开始步骤T3之前对测试用例进行调试而获得的测试用例，本公开的实施例对此不作限制。
本公开的实施例基于上述的测试用例验证流程，可以实现具有一定普适性的自动化流程，从而实现简洁高效、复用性强的硬件加速测试方法和流程，大幅节约了芯片验证工程的时间，极大提升了芯片验证效率。
图8为本公开至少一实施例提供的一种电子设备的结构示意图，该电子设备400包括处理模块410和存储器420，其中，存储器420上存储有计算机程序，计算机程序被处理模块410执行时，实现本公开至少一些实施例的验证方法。
本公开实施例中的电子设备可以包括但不限于诸如笔记本电脑、平板电脑等的移动终端以及诸如台式计算机、常规服务器、云服务器等的固定终端。图8示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
例如，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处处理模块执行时，执行本公开实施例的验证方法。
需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开的实施例中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多 种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。
上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。
需要说明的是，本公开的实施例中，电子设备400的具体功能和技术效果可以参考上文中关于验证方法的描述，此处不再赘述。
有以下几点需要说明：
(1)本公开实施例附图只涉及到本公开实施例涉及到的结构，其他结构可参考通常设计。
(2)在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合以得到新的实施例。
以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (20)

  1. 一种验证系统，包括仿真验证设备以及分别创建在所述仿真验证设备上的第一部分和第二部分，其中，
    所述第一部分包括分别与待测对象连接的第一主模块和至少一个第二从模块；
    所述待测对象包括待测模块和连接在所述待测模块的外围的多个对象接口，所述多个对象接口包括访存接口，所述第二从模块包括存储单元，所述存储单元与所述访存接口连接；
    所述第二部分包括第一直接编程接口、第二直接编程接口、函数库模块和测试用例模块，所述测试用例模块配置为提供至少一个测试用例；
    所述第一直接编程接口与所述第一主模块通信，且所述第一直接编程接口配置为：响应于运行所述测试用例，调用所述函数库模块中的至少一个第一函数，以实现所述待测模块的寄存器的前门访问；
    所述第二直接编程接口与所述第一部分的所述存储单元通信，且所述第二直接编程接口配置为：响应于运行所述测试用例，调用所述函数库模块中的至少一个第二函数，以实现所述存储单元的后门访问。
  2. 如权利要求1所述的验证系统，其中，
    所述第一部分为硬件侧，所述硬件侧配置为基于硬件描述语言创建；
    所述第二部分为软件侧，所述软件侧配置为基于行为建模语言创建。
  3. 如权利要求1或2所述的验证系统，其中，
    所述仿真验证设备包括第一处理器，所述第一处理器包括并行连接的多个第二处理器。
  4. 如权利要求3所述的验证系统，其中，
    所述仿真验证设备包括Palladium设备，所述第一直接编程接口包括基于C语言或CPP语言的直接编程接口，所述第二直接编程接口包括基于C语言或CPP语言的一次性访问型的直接编程接口。
  5. 如权利要求1～4任一项所述的验证系统，其中，所述第一部分还包括用于提供时钟信号的时钟激励源模块，所述多个对象接口还包括第一接口、第二接口、第三接口、第四接口中的至少一个；
    所述第一接口与所述时钟激励源模块连接，以接收所述时钟信号；
    所述第二接口配置为接收中断请求信号；
    所述第一主模块与所述第三接口连接，以用于配置所述待测模块的寄存器；
    所述第一主模块与所述第四接口连接，以用于复位所述第一部分。
  6. 如权利要求5所述的验证系统，其中，
    所述第一主模块包括高级微处理器总线架构式的主模块，所述第二从模块包括高级微处理器总线架构式的从模块；
    所述第一主模块包括主核和第三从模块，所述主核分别与所述第一直接编程接口和所述第三接口连接，使得所述主核获取对应于所述测试用例的所述第一函数的寄存器访存指令，以用于配置所述待测模块的寄存器；
    所述第三从模块分别连接所述主核和所述第四接口，将所述主核产生的复位信号传输至所述第四接口，以用于复位所述第一部分。
  7. 如权利要求1～6任一项所述的验证系统，其中，
    所述第一部分还包括速率匹配桥，所述速率匹配桥分别与所述第二从模块以及所述访存接口连接。
  8. 如权利要求2所述的验证系统，其中，所述第二部分还包括配置文件，
    所述测试用例配置为基于所述配置文件的所述至少一个第一函数进行用例配置，以进行所述前门访问，或者，所述测试用例配置为基于所述配置文件的所述至少一个第二函数进行用例配置，以进行所述后门访问；
    所述函数库模块包括基于所述测试用例和所述配置文件并通过所述行为建模语言编译生成的静态库。
  9. 如权利要求1～8任一项所述的验证系统，其中，
    所述至少一个第一函数包括：寄存器读函数、寄存器写函数、寄存器读后检查函数、寄存器写后读并检查函数、寄存器轮询唤醒读函数的至少一个；
    所述至少一个第二函数包括：存储单元轮询唤醒读函数、存储单元初始化函数、存储单元数据加载函数、存储单元数据导出函数中的至少一个。
  10. 如权利要求6所述的验证系统，其中，
    所述第一主模块、所述第二从模块和所述第三从模块分别被配置独立的存储空间。
  11. 一种基于如权利要求1～10任一项所述的验证系统的验证方法，包括：
    基于所述待测模块进行寄存器传输级代码编译；
    基于所述第一部分、所述待测对象、所述待测模块、所述第一主模块和所述第二从模块进行综合编译，获取已编译的所述第一部分；
    选择所述仿真验证设备的使用模式，根据所述使用模式，将已编译的所述第一部分加入至少一个编译选项，并调用第一汇编工具对所述验证系统进行解构，生成用于所述仿真验证设备的硬件信息库，以实现加速器编译；
    对所述第二部分进行行为建模语言的代码编译；
    运行已编译的所述第一部分和所述第二部分，获取验证结果。
  12. 如权利要求11所述的验证方法，其中，
    所述仿真验证设备包括Palladium设备；
    所述第一部分为硬件侧，所述硬件侧配置为基于硬件描述语言创建，所述第二部分为软件侧，所述软件侧配置为基于行为建模语言创建。
  13. 如权利要求11或12所述的验证方法，其中，所述基于所述待测模块进行寄存器传输级代码编译，包括：
    使用第二编译工具编译所述待测模块的寄存器传输级文件列表及对应寄存器传输级文件，生成包含所述待测对象的设定格式的待测模块网表，其中，生成的所述待测模块网表配置为在所述仿真验证设备上运行。
  14. 如权利要求12所述的验证方法，其中，响应于所述第一部分还包括用于提供时钟信号的时钟激励源模块，所述基于所述第一部分、所述待测对象、所述待测模块、所述第一主模块和所述第二从模块进行综合编译，获取已编译的所述第一部分，包括：
    基于所述仿真验证设备的第三编译工具对所述第一部分、所述待测对象、所述待测模块、所述第一主模块、所述第二从模块和所述时钟激励源模块进行综合编译，获取已编译的所述硬件侧。
  15. 如权利要求12所述的验证方法，其中，所述选择所述仿真验证设备的使用模式，根据所述使用模式，将已编译的所述第一部分加入至少一个编译选项，并调用第一汇编工具对所述验证系统进行解构，生成用于所述仿真验证设备的硬件信息库，包括：
    选择所述Palladium设备的IXCOM模式，根据所述IXCOM模式，将已编译的所述第一部分加入至少一个编译选项，并调用所述第一汇编工具对所述验证系统进行解构，生成所述硬件信息库。
  16. 如权利要求11～15任一项所述的验证方法，其中，所述运行已编译的所述第一部分和所述第二部分，获取验证结果，包括：
    响应于所述待测模块为第一模块，通过所述后门访问读取所述存储单元的第一数据，以获取第一参考文件；
    响应于所述待测模块为第二模块，通过所述后门访问读取所述存储单元的第二数据，以获取第二文件，其中，所述第二模块配置为基于所述第一模块进行更新的模块；
    将所述第二文件与所述第一参考文件进行对比，获取所述验证结果。
  17. 如权利要求16所述的验证方法，其中，所述通过所述后门访问读取所述存储单元的第一数据，以获取第一参考文件，包括：
    响应于所述测试用例运行结束，通过所述后门访问读取所述存储单元的所述第一数据，得到自命名的第一目标十六进制格式文件；
    基于所述第一目标十六进制格式文件生成标准版本的第二目标十六进制格式文件，获取所述第一参考文件。
  18. 如权利要求16或17所述的验证方法，其中，所述通过所述后门访问读取所述存储单元的第二数据，以获取第二文件，包括：
    对所述测试用例进行调试，运行调试之后的测试用例，通过所述后门访问读取存储单元的所述第二数据，获取所述第二文件。
  19. 一种电子设备，包括：
    处理模块和存储器，
    其中，所述存储器上存储有计算机程序，所述计算机程序被所述处理模块执行时，实现权利要求11至18中任一项所述的验证方法。
  20. 一种计算机可读存储介质，存储有计算机程序，其中，所述计算机程序被处理模块执行时，实现权利要求11至18中任一项所述的验证方法。
PCT/CN2023/115777 2022-08-31 2023-08-30 验证系统、验证方法、电子设备以及存储介质 WO2024046362A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211062729.2A CN117667655A (zh) 2022-08-31 2022-08-31 验证系统、验证方法、电子设备以及存储介质
CN202211062729.2 2022-08-31

Publications (1)

Publication Number Publication Date
WO2024046362A1 true WO2024046362A1 (zh) 2024-03-07

Family

ID=90064958

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/115777 WO2024046362A1 (zh) 2022-08-31 2023-08-30 验证系统、验证方法、电子设备以及存储介质

Country Status (3)

Country Link
CN (1) CN117667655A (zh)
TW (1) TWI837026B (zh)
WO (1) WO2024046362A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117892561A (zh) * 2024-03-14 2024-04-16 深圳市邦正精密机械有限公司 一种用于psa机的贴合压力实时监测评估方法
CN117933153A (zh) * 2024-03-21 2024-04-26 成都电科星拓科技有限公司 I3c总线验证系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112131147A (zh) * 2020-09-21 2020-12-25 成都海光微电子技术有限公司 一种控制器验证方法、装置、系统、电子设备及存储介质
US10922462B1 (en) * 2019-11-22 2021-02-16 SiFive, Inc. Intellectual property block validation and design integration for integrated circuits
CN113505066A (zh) * 2021-07-09 2021-10-15 合肥肇观电子科技有限公司 用于验证被测试模块的方法以及验证系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10503855B2 (en) * 2017-01-23 2019-12-10 Concertal Systems, Inc. Methods and systems for system design automation (SDA) of mixed signal electronic circuitry including embedded software designs
JP2022049470A (ja) * 2020-09-16 2022-03-29 キオクシア株式会社 論理シミュレーション検証システム、論理シミュレーション検証方法、およびプログラム
CN113408240B (zh) * 2021-06-25 2023-12-22 上海阵量智能科技有限公司 芯片验证方法及装置、存储介质
CN113688046B (zh) * 2021-08-26 2023-08-25 中国科学院上海高等研究院 用于处理器仿真验证的大规模用例生成方法
CN114139475A (zh) * 2021-12-07 2022-03-04 上海西井信息科技有限公司 芯片验证方法、系统、设备及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10922462B1 (en) * 2019-11-22 2021-02-16 SiFive, Inc. Intellectual property block validation and design integration for integrated circuits
CN112131147A (zh) * 2020-09-21 2020-12-25 成都海光微电子技术有限公司 一种控制器验证方法、装置、系统、电子设备及存储介质
CN113505066A (zh) * 2021-07-09 2021-10-15 合肥肇观电子科技有限公司 用于验证被测试模块的方法以及验证系统

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117892561A (zh) * 2024-03-14 2024-04-16 深圳市邦正精密机械有限公司 一种用于psa机的贴合压力实时监测评估方法
CN117933153A (zh) * 2024-03-21 2024-04-26 成都电科星拓科技有限公司 I3c总线验证系统
CN117933153B (zh) * 2024-03-21 2024-06-04 成都电科星拓科技有限公司 I3c总线验证系统

Also Published As

Publication number Publication date
TW202411872A (zh) 2024-03-16
CN117667655A (zh) 2024-03-08
TWI837026B (zh) 2024-03-21

Similar Documents

Publication Publication Date Title
CN112580295B (zh) 多核SoC芯片的自动化验证方法、系统及装置
WO2024046362A1 (zh) 验证系统、验证方法、电子设备以及存储介质
US20220292248A1 (en) Method, system and verifying platform for system on chip verification
CN102508753B (zh) Ip核验证系统
CN112949233B (zh) Fpga芯片的自动化开发方法及装置、电子设备
US7584456B1 (en) Method and apparatus for debugging embedded systems having read only memory
WO2018018978A1 (zh) 一种通用串行总线控制器验证方法、系统及设备
CN115146568B (zh) 一种基于uvm的芯片验证系统及验证方法
US10255400B1 (en) Debugging system and method
US20030149946A1 (en) Method of switching external models in an automated system-on-chip integrated circuit design verification system
JP5004566B2 (ja) 設計を検証するシステム
US7212961B2 (en) Interface for rapid prototyping system
CN102147831A (zh) 逻辑验证方法和装置
US9946823B2 (en) Dynamic control of design clock generation in emulation
US20050144436A1 (en) Multitasking system level platform for HW/SW co-verification
US20200387659A1 (en) Point-to-point module connection interface for integrated circuit generation
Gao et al. Software and hardware co-verification technology based on virtual prototyping of RF SOC
Chen et al. Me3D: A model-driven methodology expediting embedded device driver development
El-Moursy et al. Efficient embedded SoC hardware/software codesign using virtual platform
JP2013020425A (ja) オープンソースソフトウェアを利用したハードウェア・ソフトウェア協調検証方法
Lin et al. Full system simulation and verification framework
TWI427496B (zh) 製造積體電路的模型的方法和系統
CN115983172B (zh) 用于后仿真的方法和仿真平台
US20230289500A1 (en) Method and system for building hardware images from heterogeneous designs for eletronic systems
Bu et al. A configurable SystemC virtual platform for early software development and its sub-system for hardware verification

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23859391

Country of ref document: EP

Kind code of ref document: A1