Method and apparatus for initializing romcode in soc verification

Abstract

The embodiment of the present application provides a method and device for initializing Romcode in SoC verification, and belongs to the chip technical field.The method comprises the following steps: for the Romcode to be initialized, the following steps are cyclically executed until the Romcode to be initialized is traversed by rows: reading the file content which is not initialized from the Romcode to be initialized;extracting the address and data from the file content;determining the memory corresponding to the address; and storing the data into the memory address corresponding to the address of the memory, so as to complete the initialization of the file content.The method avoids the defects that the file needs to be split by address or the value needs to be continuously supplemented due to the discontinuous address of the file to be initialized, overcomes the defect that the split directional excitation is split when jumping among multiple memories, improves the automation degree of verification, and reduces the risk of accidental errors caused by manual intervention.

Description

Technical Field

[0001] This invention relates to the field of chip technology, and more specifically to a method and apparatus for initializing ROMcode in SoC verification. Background Technology

[0002] With the continuous development of chip technology, the integration level of SoCs (System on Chip) is becoming increasingly higher. Most SoCs integrate one or more CPU cores. These chips undergo module-level verification before integration. However, even after integration, the SoC still needs to be fully verified.

[0003] Currently, SoC verification is primarily based on UVM (Universal Verification Methodology). Unlike module-level verification, SoC verification, where the system is controlled by the CPU, limits the use of randomization. Therefore, the completeness of the verification largely depends on the directed stimulus. Directed stimuli are typically written in C. These C-written stimuli are converted into hex or bin format files (hereinafter referred to as hex or bin files) by a tool and initialized into memory by the verification platform. This memory includes ROM (Read-Only Memory), SRAM (Static Random-Access Memory), SDRAM (Synchronous Dynamic Random-Access Memory), OTP (One-Time Programmable) memory, flash memory, etc. In this application, files in the initialization hex or bin format, or similar formats, are collectively referred to as initialization ROMcode.

[0004] In related technologies, the ROMcode initialization method is as follows: the tool generates a hex or bin file; the initialization module in the verification platform uses the $readmemh function to read the hex or bin file; starting from memory address 0, the ROMcode is copied into the memory in one go. Summary of the Invention

[0005] The purpose of this invention is to provide a method and apparatus for initializing ROMcode in SoC verification, which at least addresses the deficiencies existing in related technologies.

[0006] To achieve the above objectives, embodiments of the present invention provide a method for initializing ROMcode in SoC verification. The method includes: for a ROMcode to be initialized, repeatedly executing the following steps until the ROMcode to be initialized is traversed line by line: reading uninitialized file content from the ROMcode to be initialized; extracting addresses and data from the file content; determining the memory corresponding to the address; and storing the data in the memory at the memory address corresponding to the address, thereby completing the initialization of the file content.

[0007] Optionally, reading uninitialized file content from the ROMcode to be initialized includes: reading a line of uninitialized file content from the ROMcode to be initialized, wherein the addresses in different lines of content can correspond to different memory locations.

[0008] Optionally, extracting addresses and data from the file content includes: processing characters associated with addresses and data in the obtained file content to obtain the addresses and data.

[0009] Optionally, determining the memory corresponding to the address includes: using a SoC address mapping relationship to determine the memory corresponding to the address, wherein the SoC address mapping relationship is pre-stored and includes an address range corresponding to each memory.

[0010] Optionally, the data is stored in the memory address corresponding to the address in the memory to complete the initialization of the file content, including: calling the corresponding array write function to write the data to the memory address in the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the memory.

[0011] Optionally, the ROMcode includes a hex file or a bin file, and the corresponding memory is one or more types of memory.

[0012] Optionally, the method is executed based on a SoC verification platform, in which a virtual interface is set for each memory, and the virtual interface is configured with the address range of the corresponding memory.

[0013] Optionally, determining the memory corresponding to the address includes: traversing the virtual interfaces to determine the memory corresponding to the address; storing the data in the memory address corresponding to the address to complete the initialization of the file content, including: providing the data and address to the corresponding virtual interface; the corresponding virtual interface calling the corresponding array write function to write the data to the memory address of the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the memory.

[0014] Optionally, the SoC verification platform adopts a dual top-level structure, which includes an HDL_TOP part and an HVL_TOP part, and the program code for executing the method is set in the bus function model part of the HDL_TOP part.

[0015] Accordingly, embodiments of the present invention also provide an apparatus for initializing ROMcode in SoC verification, the apparatus comprising: a reading module for reading uninitialized file content from ROMcode to be initialized; an extraction module for extracting addresses and data from the file content; a determination module for determining the memory corresponding to the address; a storage module for storing the data into the memory address corresponding to the address in the memory, thereby completing the initialization of the file content; and a loop execution module for repeatedly executing from the reading module for the ROMcode to be initialized until the ROMcode to be initialized is traversed line by line.

[0016] Optionally, the reading module reads uninitialized file content according to the following steps: reading a line of uninitialized file content from the Romcode to be initialized, wherein the addresses in different lines of content can correspond to different memories.

[0017] Optionally, the extraction module extracts addresses and data from the file content according to the following steps: processing the characters associated with addresses and data in the acquired file content to obtain the addresses and data.

[0018] Optionally, the determining module determines the memory corresponding to the address according to the following steps: using the SoC address mapping relationship to determine the memory corresponding to the address, wherein the SoC address mapping relationship is pre-stored and the SoC address mapping relationship includes the address range corresponding to each memory.

[0019] Optionally, the storage module stores the data in the memory address corresponding to the address in the memory according to the following steps to complete the initialization of the file content: calling the corresponding array write function to write the data to the memory address in the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the corresponding memory.

[0020] Optionally, the ROMcode includes a hex file or a bin file, and the corresponding memory is one or more types of memory.

[0021] Optionally, the device is integrated into a SoC verification platform, in which a virtual interface is set for each memory, and the virtual interface is set with the address range of the corresponding memory.

[0022] Optionally, the determining module determines the memory corresponding to the address according to the following steps: traversing the virtual interfaces to determine the memory corresponding to the address; the storage module stores the data into the memory address corresponding to the address in the memory according to the following steps to complete the initialization of the file content: providing the data and address to the corresponding virtual interface; the corresponding virtual interface calls the corresponding array write function to write the data to the memory address in the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the memory.

[0023] Optionally, the SoC verification platform adopts a dual top-level structure, which includes an HDL_TOP part and an HVL_TOP part, and the program code that forms the device is set in the bus function model part of the HDL_TOP part.

[0024] Accordingly, embodiments of the present invention also provide a machine-readable storage medium storing instructions that cause a machine to perform the above-described method.

[0025] Accordingly, embodiments of the present invention also provide a processor for running a program, wherein the program is run to execute the above-described method.

[0026] The above technical solution enables automatic determination of the corresponding memory during ROMcode initialization, and the addresses and data in the ROMcode are stored in the corresponding memory. This avoids the drawbacks of splitting the file by address or continuously padding values ​​due to non-contiguous addresses of the file to be initialized, and overcomes the shortcomings of splitting directional stimuli during multi-memory jumps, thereby improving the automation level of verification and reducing the risk of accidental errors caused by human intervention.

[0027] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0028] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings:

[0029] Figure 1 A flowchart illustrating a method for initializing ROMcode in SoC verification according to an embodiment of the present invention is shown.

[0030] Figure 2 A modular block diagram of the platform on which the method for initializing Romcode in SoC verification provided by the present invention is based is shown;

[0031] Figure 3 A flowchart of the load_hex task is shown;

[0032] Figure 4 A flowchart of the prog_memory task is shown; and

[0033] Figure 5 A structural block diagram of an apparatus for initializing ROMcode in SoC verification, provided by an embodiment of the present invention, is shown. Detailed Implementation

[0034] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the scope of the present invention.

[0035] The applicant discovered the following defects in the relevant technology:

[0036] (1) Copying data to memory requires starting from address 0 and proceeding sequentially until all content is copied. This affects some special directional stimuli, such as those requiring long jumps. The hex or bin files generated for these stimuli have non-contiguous addresses, so they must be stored according to the addresses in the hex or bin files during initialization, rather than being stored contiguously. The aforementioned related technologies cannot achieve this functionality. Typically, the ROMcode for such stimuli needs to be processed separately, such as splitting it by address and then initializing the ROMcode. In addition, extra code needs to be added to continuously pad the interrupt address. This approach is not only cumbersome to handle but also prone to errors, which can cause the CPU to hang, and it is also difficult to quickly find the problem.

[0037] (2) For directed stimuli that require jumps between multiple memories, the directed stimuli need to be split into multiple directed stimuli according to the type of memory where they are stored. Then, hex or bin files are generated and stored in memory according to the aforementioned techniques. For example, when the CPU needs to jump from ROM to SRAM to fetch instructions, a directed stimuli is usually split into two parts: one running in ROM and the other running in SRAM. Then, hex or bin files are generated and the two ROMcodes are initialized separately according to the aforementioned techniques before being stored in the corresponding memories. This approach increases the complexity of verification and the workload.

[0038] Figure 1 This diagram illustrates a flowchart of a method for initializing ROMcode in SoC verification, provided by an embodiment of the present invention. Figure 1 As shown, this embodiment of the invention provides a method for initializing ROMcode in SoC verification. The method can be executed, for example, based on a UVM-based SoC verification platform, and the program code for initializing the ROMcode can be set in the platform's bus function model section. The method may include repeatedly executing steps S110 to S140 for the ROMcode to be initialized until the ROMcode to be initialized is traversed row by row.

[0039] Step S110: Read the uninitialized file content from the Romcode to be initialized.

[0040] The ROMcode to be initialized is a hex file, bin file, or similar file for directional stimulus conversion. During execution, the file containing the ROMcode to be initialized is first opened, and then a system function can be called to retrieve the uninitialized ROMcode from the file. The system function called can be, for example, the $fgets function.

[0041] Step S120: Extract the address and data from the file content.

[0042] The extracted address can be a single address or a range of addresses.

[0043] One line of uninitialized file content can be read from the uninitialized ROMcode at a time. Each line of file content corresponds to an address or a range of addresses. The address range corresponds to a common memory location, indicating that data will be stored within that address range of the memory.

[0044] The system can process characters associated with addresses and data within the file content to extract the addresses and data. The extracted addresses and data can be formatted into a "address-data" format for easier subsequent processing. System functions, such as the `$sscanf` function, can be called to process the file content.

[0045] Step S130: Determine the memory corresponding to the address.

[0046] A SoC address mapping relationship can be pre-stored, which includes the address range corresponding to each memory. Thus, the memory corresponding to a given address can be determined using the SoC address mapping relationship.

[0047] In practice, a virtual interface can be set up for each memory in the SoC verification platform, and each virtual interface has a corresponding memory address range. By traversing the virtual interfaces, the memory corresponding to the address can be determined. The corresponding memory is one or more types of memory. The one or more types of memory include one or more of the following: ROM, SRAM, SDRAM, OTP memory, flash memory, etc.

[0048] Step S140: The data is stored in the memory address corresponding to the address in the memory to complete the initialization of the file content.

[0049] The file content initialization can be completed by calling the array write function corresponding to the memory and storing the data in the memory address corresponding to the specified address. Different memories correspond to different array write functions, which are used to convert the format of the data to be written into a format that matches the corresponding memory. The memory address for storing the data corresponds to the address extracted in step S120. It can be that the memory address for storing the data is the same as the address extracted in step S120, or it can be that the memory address for storing the data is obtained from the address extracted in step S120 based on certain calculation rules. This embodiment of the invention does not impose any specific limitations.

[0050] When a virtual interface is configured, the data and address can be provided to the virtual interface, which then calls the array write function to write the data to the corresponding memory, thereby initializing the file content. For example, the `write_word` function can be used to provide the data and address to the virtual interface.

[0051] When performing step S110, one line of uninitialized file content can be read from the ROMcode to be initialized each time. One line of file content corresponds to one address or one address range. The address range corresponds to a common memory location, indicating that the data will be stored within the address range of that memory. The ROMcode is traversed line by line in this way, so that each line of file content in the ROMcode is automatically initialized.

[0052] In a scalable scenario, when performing step S110, more than one line of uninitialized file content can be read from the ROMcode to be initialized each time. However, this approach requires performing the corresponding steps line by line in steps S120-S140. Compared to retrieving one line of file content at a time, the execution process is more complex. Therefore, it is preferable that when performing step S110, one line of uninitialized file content can be retrieved from the ROMcode to be initialized each time.

[0053] To determine whether the ROMcode has been completely traversed, a system function can be used to check the ROMcode file status, such as the `$feof` function. If the ROMcode has not been completely traversed, the loop continues. If the traversal is complete, the initialization process ends. The SoC verification process then enters the next state, the simulation state.

[0054] The method for initializing ROMcode in SoC verification provided by this invention can automatically determine the corresponding memory during ROMcode initialization and store the addresses and data in the ROMcode into the corresponding memory. This avoids the drawbacks of splitting the file by address or continuously padding values ​​due to non-contiguous addresses of the file to be initialized, and also overcomes the shortcomings of splitting directional stimuli during multi-memory jumps, improving the automation level of verification and reducing the risk of accidental errors caused by manual intervention.

[0055] Figure 2 A modular block diagram of the platform on which the method for initializing ROMcode in SoC verification provided by this invention is based is shown. Figure 2As shown, the method for initializing ROMcode in SoC verification provided in this embodiment of the invention can be executed on a UVM-based SoC verification platform. The platform can adopt a dual-top-level structure, consisting of an HDL_TOP section related to the register level (RTL) and an HVL_TOP section related to the abstraction and behavioral levels (i.e., a standard UVM verification platform). The program code for initializing ROMcode in SoC verification is set in the Bus Function Model (BFM) section of the HDL_TOP section. Figure 2 In this context, ".sv" indicates that the code was written in the SV language, and "DUT" represents the device to be verified, i.e., the SoC under test. The DUT and the HVL_TOP section interact through the config_db mechanism in UVM.

[0056] The code module that initializes Romcode does not interact with the HVL_TOP section; it is equivalent to an independent module running in the HDL_TOP section.

[0057] The `memory_gasket` ​​module instantiates an interface queue and a storage array initialization module. The interface queue includes virtual interfaces set up for each memory, such as the SRAM virtual interface, OTP memory virtual interface, flash memory virtual interface, and SDRAM virtual interface shown in the diagram. In practice, only one interface needs to be written and declared as a virtual type to instantiate an interface array. The storage array initialization module includes initialization modules for each memory, such as `sram_gasket`, `otp_gasket`, `flash_gasket`, and `sdram_gasket` ​​shown in the diagram. The interface queue sets the address range of the corresponding memory; by traversing the interface queue, the memory corresponding to the address of the data to be initialized can be determined. Setting up an interface queue and a storage array initialization module eliminates the need to use macro definitions to distinguish memory types during initialization, making the verification environment cleaner. Furthermore, only the size of the interface queue needs to be changed to increase or decrease the number of memories requiring initialization, reducing modifications to other files on the verification platform. Figure 2 The virtual interfaces listed herein are for illustrative purposes only and are not restrictive. Virtual interfaces may be set up for other or any other type of memory if needed.

[0058] Taking a hex file as an example, the memory_gasket module has two tasks: load_hex and prog_memory. The load_hex task handles the hex file format and determines the hex file read status, while the prog_memory task handles the writing of data in the hex file.

[0059] At time 0 of the SoC verification, the load_hex task in the memory_gasket module is first invoked. The load_hex task can execute steps S110 to S120 as described above. The execution flow of this task is as follows: Figure 3 As shown. First, it checks if a hex file exists. If not, the verification ends. If it exists, the hex file is opened. Then, the `$fgets` function is used to read the uninitialized line of hex file content. The `$sscanf` function is used to process characters associated with addresses and data in the file content to extract the addresses and data, and convert the extracted addresses and data to "address-data" format. After extracting the addresses and data, the `prog_memory` task is called to initialize the line of hex file content. The `$feof` function is used to check the hex file status. If it has not been completely read, the next uninitialized line of hex file content is retrieved to repeat the above steps. If it has been completely read, the `load_hex` task ends, and the verification begins.

[0060] This section uses SRAM or OTP memory as an example to illustrate the execution flow of the prog_memory task. The prog_memory task is mainly used to execute steps S130 to S140 mentioned above. Figure 4 As shown, the process first involves traversing the interface queue to determine the memory corresponding to the extracted address. If the address corresponds to SRAM (i.e., it belongs to the SRAM address), the address and data are provided to the SRAM virtual interface by calling the `write_word` function. Then, the SRAM virtual interface calls the SRAM array write function and writes the data to the SRAM according to the address to complete the initialization of the file content. The SRAM array write function can convert the data format to a format compatible with the SRAM. Similarly, if the address corresponds to OTP memory (i.e., it belongs to the OTP memory address), the address and data are provided to the OTP memory virtual interface by calling the `write_word` function. Then, the OTP memory virtual interface calls the OTP memory array write function and writes the data to the OTP memory according to the address to complete the initialization of the file content. The OTP memory array write function can convert the data format to a format compatible with the OTP memory.

[0061] The array write function corresponding to the memory can be named, for example, `act_write_byte`. Depending on the type of memory, this function needs to be defined beforehand in the `sram_gasket` ​​module.

[0062] The method for initializing ROMcode in SoC verification provided in this invention can automatically determine the memory to be initialized during initialization and can automatically switch between multiple memories. This avoids the drawbacks of splitting files by address or continuously padding values ​​due to non-contiguous addresses of the files to be initialized, and also overcomes the shortcomings of splitting directional stimuli during multi-memory jumps, improving the automation level of verification and reducing the risk of accidental errors caused by manual intervention.

[0063] Figure 5 A structural block diagram of an apparatus for initializing ROMcode in SoC verification, provided by an embodiment of the present invention, is shown. Figure 5 As shown, this embodiment of the invention also provides an apparatus for initializing ROMcode in SoC verification. The apparatus includes: a reading module 520 for reading uninitialized file content from ROMcode to be initialized; an extraction module 530 for extracting addresses and data from the file content; a determination module 540 for determining the memory corresponding to the address; a storage module 550 for storing the data in the memory at the memory address corresponding to the address, thereby completing the initialization of the file content; and a loop execution module 510 for repeatedly executing from the reading module for the ROMcode to be initialized until the ROMcode to be initialized is traversed line by line.

[0064] In some alternative embodiments, the reading module 520 may read uninitialized file content according to the following steps: reading a line of uninitialized file content from the Romcode to be initialized, wherein the addresses in different lines of content can correspond to different memories.

[0065] In some alternative embodiments, the extraction module 530 extracts addresses and data from the file content according to the following steps: processing characters associated with addresses and data in the acquired file content to obtain the addresses and data.

[0066] In some alternative embodiments, the determining module 540 determines the memory corresponding to the address according to the following steps: using a SoC address mapping relationship to determine the memory corresponding to the address, wherein the SoC address mapping relationship is pre-stored and includes an address range corresponding to each memory.

[0067] In some optional embodiments, the storage module 550 stores the data into the memory address corresponding to the address in the memory according to the following steps to complete the initialization of the file content: calling the corresponding array write function to write the data to the memory address in the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the corresponding memory.

[0068] In some alternative embodiments, the ROMcode includes a hex file or a bin file, and the corresponding memory is one or more types of memory.

[0069] In some alternative embodiments, the device is integrated into a SoC verification platform, in which a virtual interface is set for each memory, and the virtual interface is set with the address range of the corresponding memory.

[0070] In some optional embodiments, the determining module 540 determines the memory corresponding to the address according to the following steps: traversing the virtual interface to determine the memory corresponding to the address; the storage module 550 stores the data into the memory address corresponding to the address according to the following steps to complete the initialization of the file content: providing the data and address to the corresponding virtual interface; the corresponding virtual interface calls the corresponding array write function to write the data to the memory address of the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the memory.

[0071] In some alternative embodiments, the SoC verification platform adopts a dual top-level structure, which includes an HDL_TOP part and an HVL_TOP part, and the program code that forms the device is set in the bus function model part of the HDL_TOP part.

[0072] The apparatus for initializing ROMcode in SoC verification provided in the embodiments of the present invention may include a processor and a memory. The aforementioned modules may be stored in the memory as program units, and the processor executes the program units stored in the memory to implement the method for initializing ROMcode in SoC verification according to any embodiment of the present invention.

[0073] The processor contains a kernel that retrieves the corresponding program unit from memory. One or more kernels can be configured, and their parameters can be adjusted to execute the method for initializing ROMcode in SoC verification according to any embodiment of the present invention.

[0074] The memory may include non-permanent memory in computer-readable media, random access memory and / or non-volatile memory, such as read-only memory or flash memory, and the memory includes at least one memory chip.

[0075] The specific working principle and benefits of the device for initializing Romcode in SoC verification provided in this embodiment of the invention are the same as those of the method for initializing Romcode in SoC verification provided in this embodiment of the invention, and will not be repeated here.

[0076] This invention also provides a machine-readable storage medium storing instructions that cause a machine to execute a method for initializing ROMcode in SoC verification according to any embodiment of the invention.

[0077] This invention also provides a processor for running a program, wherein the program executes a method for initializing ROMcode in SoC verification according to any embodiment of the invention.

[0078] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0079] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0080] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0081] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0082] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0083] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0084] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0085] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0086] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for initializing ROMcode in SoC verification, characterized in that, The method includes: For the ROMcode to be initialized, repeat the following steps until the ROMcode to be initialized has been traversed line by line: Read the uninitialized file content from the Romcode to be initialized; Extract the address and data from the file content; Determine the memory corresponding to the address; and The data is stored in the memory address corresponding to the address in the memory to complete the initialization of the file content; The method is executed based on a SoC verification platform, in which a virtual interface is set for each memory, and the virtual interface is set with the address range of the corresponding memory. Determining the memory corresponding to the address includes: traversing the virtual interface to determine the memory corresponding to the address; The data is stored in the memory address corresponding to the address in the memory to complete the initialization of the file content, including: providing the data and address to the corresponding virtual interface; the corresponding virtual interface calls the corresponding array write function to write the data to the memory address in the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the memory.

2. The method according to claim 1, characterized in that, Reading uninitialized file content from the uninitialized Romcode includes: Read a line of uninitialized file content from the Romcode to be initialized, where the addresses in different lines can correspond to different memory locations.

3. The method according to claim 1, characterized in that, Extracting addresses and data from the file content includes: Process the characters associated with the address and data in the obtained file content to obtain the address and data.

4. The method according to claim 1, characterized in that, Determining the memory corresponding to the address includes: The memory corresponding to the address is determined using the SoC address mapping relationship, wherein the SoC address mapping relationship is pre-stored and includes the address range corresponding to each memory.

5. The method according to claim 1, characterized in that, The data is stored in the memory address corresponding to the address in the memory to complete the initialization of the file content, including: The corresponding array write function is called to write the data to the memory address of the memory to complete the initialization of the file content. The array write function is used to convert the format of the data into a format that matches the memory.

6. The method according to claim 1, characterized in that, The ROMcode includes a hex file or a bin file, and the corresponding memory is one of one or more memory types.

7. The method according to claim 1, characterized in that, The SoC verification platform adopts a dual top-level structure, which includes an HDL_TOP part and an HVL_TOP part. The program code for executing the method is set in the bus function model part of the HDL_TOP part.

8. An apparatus for initializing ROMcode in SoC verification, characterized in that, The device includes: The read module is used to read the contents of an uninitialized file from the uninitialized Romcode; The extraction module is used to extract addresses and data from the file content; The determining module is used to determine the memory corresponding to the address; A storage module is used to store the data into a memory address corresponding to the specified address in the memory, thereby completing the initialization of the file content; and The loop execution module is used to repeatedly execute the reading module for the ROMcode to be initialized until the ROMcode to be initialized has been traversed line by line. The device is integrated into a SoC verification platform, in which a virtual interface is set for each memory, and the virtual interface is set with the address range of the corresponding memory. The determining module determines the memory corresponding to the address according to the following steps: traversing the virtual interface to determine the memory corresponding to the address; The storage module stores the data into the memory address corresponding to the address in the memory according to the following steps to complete the initialization of the file content: providing the data and address to the corresponding virtual interface; the corresponding virtual interface calls the corresponding array write function to write the data to the memory address in the memory to complete the initialization of the file content, wherein the array write function is used to convert the format of the data into a format that matches the memory.

9. The apparatus according to claim 8, characterized in that, The reading module reads the contents of an uninitialized file according to the following steps: Read a line of uninitialized file content from the Romcode to be initialized, where the addresses in different lines can correspond to different memory locations.

10. The apparatus according to claim 8, characterized in that, The extraction module extracts addresses and data from the file content according to the following steps: Process the characters associated with the address and data in the obtained file content to obtain the address and data.

11. The apparatus according to claim 8, characterized in that, The determining module determines the memory corresponding to the address according to the following steps: The memory corresponding to the address is determined using the SoC address mapping relationship, wherein the SoC address mapping relationship is pre-stored and includes the address range corresponding to each memory.

12. The apparatus according to claim 8, characterized in that, The storage module stores the data into the memory address corresponding to the address in the memory according to the following steps to complete the initialization of the file content: The corresponding array write function is called to write the data to the memory address of the memory to complete the initialization of the file content. The array write function is used to convert the format of the data into a format that matches the corresponding memory.

13. The apparatus according to claim 8, characterized in that, The ROMcode includes a hex file or a bin file, and the corresponding memory is one of one or more memory types.

14. The apparatus according to claim 8, characterized in that, The SoC verification platform adopts a dual top-level structure, which includes an HDL_TOP part and an HVL_TOP part. The program code that forms the device is set in the bus function model part of the HDL_TOP part.

15. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the method according to any one of claims 1-7.

16. A processor, characterized in that, Used to run a program, wherein the program is run to perform the method according to any one of claims 1-7.

Images