Methods for testing read-only memory programs, design under test, test equipment and media

Abstract

This invention relates to the field of program testing technology, and discloses a method for testing read-only memory (ROM) programs, a design under test (DUT), testing equipment, and a medium. The method for testing ROM programs includes the following steps: controlling at least one write port to an unavailable state, driving the DUT to run a target test program; reading and running the target test program through at least one read port, obtaining the running results, and determining whether the test program has errors based on the running results; if the running results determine that the test program has errors, generating an updated test program based on the errors, controlling at least one write port to an available state, writing the updated test program into the test memory through at least one write port, using the updated test program as the new target test program, executing the step of controlling at least one write port to an unavailable state, and subsequent steps. This invention can effectively save a significant amount of manpower and resources and improve testing efficiency.

Description

Technical Field

[0001] This invention relates to the field of program testing technology, and in particular to a method for testing read-only memory programs, a design under test, a test device, and a medium. Background Technology

[0002] The program code stored inside ROM (Read-Only Memory) is permanently embedded in the chip during the chip manufacturing process and cannot be modified afterward. If errors occur in the program code within the ROM, it may cause the chip or smart device containing the ROM to malfunction. Therefore, it is necessary to verify the correctness of the ROM's program code before manufacturing.

[0003] A chip prototyping platform can be used to load ROM program code into a ROM module constructed based on an FPGA (Field-Programmable Gate Array) for verification. However, in the early stages of ROM program debugging, the written code inevitably contains many errors, requiring multiple updates and repairs. Each update to the ROM program code necessitates updating all project files on the prototyping platform before loading it into the FPGA for verification, which is labor-intensive and time-consuming, resulting in low testing efficiency. Summary of the Invention

[0004] Based on this, it is necessary to address the above problems by proposing a method for testing read-only memory programs, the design under test, the test equipment, and the media.

[0005] A method for testing a read-only memory program, applied to a design under test, the design under test including a test accessor storing a target test program, including at least one write port and at least one read port;

[0006] The method for testing the program of the read-only memory includes the following steps:

[0007] Control the at least one write port to be in an unavailable state, and drive the design under test to run the target test program;

[0008] The target test program is read and run through at least one read port, the running results are obtained, and it is determined whether the test program has any errors based on the running results.

[0009] If the test program is determined to have an error based on the running results, an updated test program is generated based on the error, the at least one write port is made available, the updated test program is written into the test accessor through the at least one write port, the updated test program is used as a new target test program, the step of making the at least one write port unavailable is executed, and subsequent steps are performed.

[0010] Prior to the step of writing the update test program into the test accessor through the at least one write port, the following steps are included:

[0011] Reset the design under test to its initial state;

[0012] After the step of writing the update test program into the test accessor through the at least one write port, the following is included:

[0013] Release the reset of the design under test, so that the design under test recovers from the initial state.

[0014] Prior to the step of controlling the at least one write port to be in an unavailable state, the following steps are included:

[0015] By using cross-module referencing technology, at least one write port is connected to the outside of the design under test (DUT), so that the at least one write port can be controlled by a control device outside the DUT without requiring any modifications to the DUT.

[0016] The step of connecting the at least one write port to the outside of the design under test via cross-module referencing technology includes:

[0017] Obtain the compiled project file based on the chip prototype verification platform and testing requirements, load the project file into the chip prototype verification platform, and run the project file.

[0018] The step of determining whether the test program has errors based on the running results includes:

[0019] If the test program is determined to be error-free based on the test results, then subsequent verification tests will continue.

[0020] The at least one write port includes: a write enable port, a write data port, and a write address port;

[0021] The step of controlling the at least one write port to be in an unavailable state includes:

[0022] Control the write enable port to the first active level; or

[0023] The write enable port, the write data port, and the write address port are all controlled to be at the first valid level;

[0024] The step of controlling the at least one write port to be in an available state includes:

[0025] Control the write enable port to the second active level; or

[0026] The write enable port, the write data port, and the write address port are all controlled to be at the second active level.

[0027] A chip prototype verification platform, and a method for running a test read-only memory program as described above, comprising:

[0028] The design under test includes a device under test (DUT) module, which includes a test accessor that stores a target test program and includes at least one write port and at least one read port.

[0029] A logic control circuit, connected to the at least one write port, is used to control the state of the at least one write port to be available or unavailable.

[0030] The interface module connects to the logic control circuit at one end and to a test computer outside the design under test at the other end. It is used to receive updated test programs provided by the test computer, so that the updated test programs can be written into the test memory through the logic control circuit.

[0031] When the target test program in the test accessor needs to be verified, the logic control circuit controls the at least one write port to be in an unavailable state.

[0032] When it is necessary to update the target test program in the test accessor, the logic control circuit controls the at least one write port to be in an available state, so that the updated test program provided by the test computer can be written into the test accessor through the logic control circuit.

[0033] A computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the steps described above.

[0034] A testing device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps described above.

[0035] The embodiments of the present invention have the following beneficial effects:

[0036] By controlling the state of at least one write port of the test accessor, the test accessor can switch between the state of the RAM module and the state of the ROM module. When updating the target test program, at least one write port is in an available state, and the project file does not need to be updated. The original project file is still used. The target test program is written to the test accessor through at least one write port. Then, at least one write port is adjusted to an unavailable state for verification testing. When testing the program in the ROM, there is no need to update the entire project file. Only the target test program needs to be updated to complete a new round of verification testing, saving a lot of manpower and resources and improving testing efficiency. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] in:

[0039] Figure 1 This is a schematic diagram of the block RAM structure of the RAM module provided by the present invention;

[0040] Figure 2 This is a schematic diagram of the block RAM structure of the ROM module provided by the present invention;

[0041] Figure 3 A schematic diagram illustrating an application scenario of the method for testing read-only memory programs provided by the present invention;

[0042] Figure 4 This is a flowchart illustrating an embodiment of the method for testing read-only memory programs provided by the present invention;

[0043] Figure 5 This is a flowchart illustrating another embodiment of the method for testing read-only memory programs provided by the present invention;

[0044] Figure 6 This is a schematic diagram of the structure of an embodiment of the chip prototype verification platform provided by the present invention;

[0045] Figure 7 This is a schematic diagram of the structure of an embodiment of the testing equipment provided by the present invention;

[0046] Figure 8 This is a schematic diagram of an embodiment of the computer-readable storage medium provided by the present invention. Detailed Implementation

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

[0048] When the program in the ROM is relatively simple, it can usually be verified using EDA simulation tools. However, when the program in the ROM is complex, verification using EDA simulation tools will be very time-consuming. For example, the program in the chip's boot ROM includes operations such as initialization and read / write of some peripherals; if verified using EDA simulation tools, a single simulation verification could take several days. In this case, a chip prototyping platform can be used to load the ROM program code into a ROM module constructed based on an FPGA (Field Programmable Gate Array) for verification.

[0049] On the chip prototyping platform, both RAM and ROM modules can be mapped to functional modules within the FPGA, i.e., Block RAM (BRAM). Please refer to [reference needed]. Figure 2 and Figure 3 , Figure 2 This is a schematic diagram of the block RAM structure of the RAM module provided by the present invention. Figure 3 This is a schematic diagram of the block RAM structure of the ROM module provided by this invention. The block RAM of the RAM module has three write ports: write enable wr_en, write address wr_addr, and write data wr_data, and three read ports: read enable rd_en, read address rd_addr, and read data rd_data. The block RAM of the ROM module only has three read ports: read enable rd_en, read address rd_addr, and read data rd_data. The three write ports, write enable wr_en, write address wr_addr, and write data wr_data, are in an unavailable state.

[0050] See also Figure 1 and Figure 2It is known that the difference between the block RAM of the ROM module and the block RAM of the RAM module lies in three write ports: the write enable (wr_en), write address (wr_addr), and write data (wr_data) of the ROM module are unavailable, while these three ports of the RAM module are available. In this invention, by utilizing the difference between the block RAM of the ROM module and the block RAM of the RAM module, and controlling the states of the three write ports (wr_en, wr_addr, and wr_data) of the RAM module, it is possible to switch between states equivalent to those of the RAM module and states equivalent to those of the ROM module.

[0051] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating an application scenario of the method for testing read-only memory programs provided by the present invention. In this embodiment, a design under test (DUT) 10 is used to verify and test a target test program. The DUT includes a test accessor 11. The test accessor 11 is a block RAM structure of a RAM module. Its three write ports, namely write enable (wr_en), write address (wr_addr), and write data (wr_data), are in a controllable state, which can be controlled to be usable or unusable. When the three write ports are controlled to be unusable, the test accessor 11 is equivalent to a ROM module structure, which can only read data from it and cannot write data. When the three write ports are controlled to be usable, the test accessor 11 is equivalent to a RAM module structure, which can not only read data from it but also write data to it. Therefore, by controlling the state of at least one write port, the test accessor 11 can be controlled to be either a ROM module structure or a RAM module structure.

[0052] By controlling at least one write port of the test accessor 11 to be unavailable (the test accessor 11 is equivalent to a ROM module), the design under test 10 is driven to run the target test program, simulating the execution of the target test program in the ROM. The controller of the design under test 10 (e.g., CPU or MCU) reads the target test program through at least one read port, runs the target test program, and obtains the result of this execution. Based on the result, it determines whether there are any errors in the target test program. If there are errors in the target test program, an updated target test program to correct the errors is obtained. The test accessor 11 is then controlled to be available (the test accessor 11 is equivalent to a RAM module), allowing the updated test program to be written into the test accessor 11 through at least one write port. The updated test program is then used as the target test program. The steps of controlling at least one write port of the test accessor 11 to be unavailable and driving the design under test 10 to run the new target test program, as well as subsequent steps, are repeatedly executed until the verification test passes. In this way, when updating the target test program, the project file does not need to be updated; the original project file is still used, saving a lot of manpower and resources and improving testing efficiency.

[0053] Please refer to the following: Figure 3 and Figure 4 , Figure 4 This is a flowchart illustrating an embodiment of the method for testing read-only memory programs provided by the present invention. In this embodiment, the program code in the Boot ROM is to be verified. Due to its high complexity, a chip prototype verification platform is needed to verify the Boot ROM program code. The chip prototype verification platform is built from multiple FPGA chips.

[0054] The method for testing read-only memory programs provided by this invention includes the following steps:

[0055] S101: Controls at least one write port to be in an unavailable state, driving the design under test to run the target test program.

[0056] In a specific implementation scenario, the state of the three write ports can be controlled by writing to the port that enables wr_en. That is, when the three write ports need to be disabled, this can be achieved by setting the write enable wr_en port to the first valid level (e.g., 0), or by setting the write enable wr_en, write address wr_addr, and write data wr_data of all three write ports to the first valid level. When the three write ports need to be enabled, this can be achieved by setting the write enable wr_en port to the second valid level (e.g., 1), or by setting the write enable wr_en, write address wr_addr, and write data wr_data of all three write ports to the second valid level.

[0057] The test memory stores the target test program, which is the program to be burned into the Boot ROM. It needs to be verified before burning. During verification, the test memory is set to a state equivalent to the ROM module, simulating the running state of the Boot ROM to verify the correctness of the target test program. Therefore, at least one write port is first disabled; in this state, the test memory functions like a ROM module, driving the design under test to run the target test program.

[0058] S102: Read the target test program through at least one read port and run it to obtain the running results. Determine whether there are any errors in the target test program based on the running results. If so, proceed to step S103.

[0059] In a specific implementation scenario, the controller of the design under test (DUT) reads the target test program through a read port (e.g., the rd_data port) and runs the target test program. After the target test program finishes running, the state of at least one write port is not adjusted; at this point, the test accessor is still equivalent to a ROM module. The running results are compared with preset standard results, and the presence of errors in the test program is determined based on the comparison results. For example, if the running results are inconsistent with the standard results, it can be determined that the target test program contains errors.

[0060] S103: Generate an update test program based on the error, control at least one write port to be in an available state, write the update test program into the test accessor through at least one write port, use the update test program as the target test program, and execute step S101.

[0061] In a specific implementation scenario, if the target test program contains errors, the original target test program is updated based on the identified errors, generating an updated test program. The updated test program needs to be written to the test memory for execution to verify its correctness. Therefore, the test memory needs to be adjusted from a state equivalent to a ROM module to a state equivalent to a RAM module so that data can be written to it.

[0062] In this implementation scenario, at least one write port is kept in an available state. The test accessor is equivalent to a RAM module, and the update test program is written into the test accessor through at least one write port. After the update test program is successfully written, it needs to be used as the new target test program for the test steps described above.

[0063] Specifically, after updating the test program as the new target test program, at least one write port is made unavailable, and the test access device is adjusted from a state equivalent to a RAM module to a state equivalent to a ROM module to verify the new target test program. The test access device is driven to run the target test program, and the running results are obtained through at least one read port. Based on the running results, it is determined whether there are any errors in the test program. If errors are still found, a new updated test program is obtained, and the above steps are repeated until the test program passes verification.

[0064] In other implementation scenarios, if the target test program does not contain errors, the subsequent verification steps will continue. This could include testing other modules or performing other functional tests.

[0065] By implementing the above steps, when verifying the BootROM program, the test accessor switches between RAM module and ROM module states by controlling the state of at least one write port. When data needs to be written to the test accessor, at least one write port is made available, allowing data to be written through it. When the target test program needs to be run, at least one write port is made unavailable, making the test accessor function like a ROM module and simulating the Boot ROM to run the target test program. When updating the target test program, the project file does not need to be updated; the original project file is still used, as the target test program has already been written to the test accessor through at least one write port. This saves significant manpower and resources and improves testing efficiency.

[0066] As described above, in this embodiment, by controlling the state of at least one write port of the test accessor, the test accessor can switch between the state of the RAM module and the state of the ROM module. When updating the target test program, at least one write port is in an available state, and the project file does not need to be updated; the original project file is still used. The target test program is written to the test accessor through at least one write port. Then, at least one write port is adjusted to an unavailable state for verification testing. When testing the program in the ROM, there is no need to update the entire project file; only the target test program needs to be updated to complete a new round of verification testing, saving a lot of manpower and resources and improving testing efficiency.

[0067] Please refer to the following: Figure 3 and Figure 5 , Figure 5 This is a schematic flowchart of another embodiment of the method for testing read-only memory programs provided by the present invention. The method for testing read-only memory programs provided by the present invention includes the following steps:

[0068] S201: Connect at least one write port to the outside of the design under test using cross-module referencing technology, so that a control device outside the design under test can control at least one write port.

[0069] In a specific implementation scenario, to minimize modifications to the DUT (Design Under Test) code, and because at least one write port needs to be connected to an external device for status control or to receive update test programs, XMR (Cross Module Reference) technology is used to connect at least one write port to the external DUT. This allows for connection between at least one write port and an external control device without any modifications to the DUT, enabling the external control device to control at least one write port and input data to the test accessor through it. This further reduces the workload of verification testing and improves testing efficiency.

[0070] S202: Obtain the compiled project file based on the chip prototype verification platform and test requirements, load the project file into the chip prototype verification platform, and run the project file.

[0071] In a specific implementation scenario, the chip prototyping platform is built around an FPGA chip. A Design Under Test (DUT) is constructed based on testing requirements, and the DUT includes a test accessor. Once the DUT, test environment, and test logic are ready, the project file is compiled using EDA (Electronic Design Automation) software. The compiled project file is then loaded onto the chip prototyping platform, the DUT is released and reset, and the project file is run.

[0072] The project file includes the target test program that needs to be stored in the test accessor. When the project file is run, the target test program is written into the test accessor.

[0073] S203: Controls at least one write port to be in an unavailable state, driving the design under test to run the target test program.

[0074] S204: Read and run the target test program through at least one read port, obtain the running results, and determine whether there are any errors in the target test program based on the running results. If not, proceed to step S205.

[0075] In a specific implementation scenario, steps S203-S204 are basically the same as steps S101-S102 in one embodiment of the method for testing read-only memory programs provided by the present invention, and will not be described again here.

[0076] S205: Reset the design under test to its initial state.

[0077] In a specific implementation scenario, due to an error in the target test program, the DUT running the target test program is in an abnormal state. In order to ensure that the test program can be updated smoothly in the future, the design under test is reset to the initial state so that the state of the DUT is normal during subsequent tests.

[0078] S206: Generate an updated test program based on the error, ensure at least one write port is available, and write the updated test program to the test accessor through at least one write port. Use the updated test program as the new target test program.

[0079] In a specific implementation scenario, step S206 is basically the same as step S103 in one embodiment of the method for testing read-only memory programs provided by the present invention, and will not be described again here.

[0080] S207: Release the reset of the design under test, allowing the design under test to recover from its initial state.

[0081] In a specific implementation scenario, the DUT is released from its reset state, recovers from its initial state, and reads the new target test program from the test accessor to begin re-verifying the target test program. Step S203 and subsequent steps are repeated until the verification test of the new target test program passes.

[0082] As described above, in this embodiment, the DUT is reset before updating the target test program in the test accessor. This prevents the DUT from being in an abnormal state due to running an erroneous target test program, which could cause problems in subsequent verification of the new target test program and effectively improves the reliability of the test.

[0083] It is understood that the method of the present invention can be applied to the testing and verification of BOOT ROM or ordinary ROM, and can also be applied to ROMs with other functions in the chip.

[0084] Please see Figure 5 , Figure 5 This is a schematic diagram of an embodiment of the chip prototype verification platform provided by the present invention. The chip prototype verification platform 20 is used to implement... Figure 4 or Figure 5 The method for testing read-only memory programs shown includes a chip prototype verification platform 20 comprising a design under test 21, a logic control circuit 22, and a general interface module 23.

[0085] The design under test (DUT) 21 includes a DUT module 211 and at least one other DUT functional module 212. The DUT module 211 includes a test accessor 2111, which stores a target test program and includes at least one write port and at least one read port. In this implementation scenario, there are three write ports: write enable (wr_en), write address (wr_addr), and write data (wr_data). There are three read ports: read enable (rd_en), read address (rd_addr), and read data (rd_data).

[0086] The logic control circuit 22 is connected to at least one write port and is used to control the state of at least one write port to be either available or unavailable. In this implementation scenario, the logic control circuit 22 is connected to three write ports.

[0087] One end of the general interface module 23 is connected to the logic control circuit 22, and the other end is connected to the test computer outside the design under test 21. It receives updated test programs provided by the test computer, enabling the updated test programs to be written into the test memory 2111 via the logic control circuit 22. In this implementation scenario, the three write ports are connected to the logic control circuit 22 via XMR, allowing the logic control circuit 22 to connect to and control at least one write port without modifying the design under test 21.

[0088] When the target test program in test accessor 2111 needs to be verified, logic control circuit 22 controls at least one write port to be in an unavailable state, so that the design under test 211 can complete the verification test of the benchmark test program. When the target test program in test accessor 2111 needs to be updated, logic control circuit 22 controls at least one write port to be in an available state, so that the updated test program provided by the test computer can be written into test accessor 2111 through logic control circuit 22.

[0089] As described above, in this embodiment, when updating the target test program, the project file does not need to be updated and the original project file is still used. The target test program is written to the test accessor through at least one write port, and then at least one write port is adjusted to an unavailable state for verification testing. When testing the program in the ROM, there is no need to update the entire project file. Only the target test program needs to be updated to complete a new round of verification testing, which saves a lot of manpower and resources and improves testing efficiency.

[0090] Please see Figure 7 , Figure 7This is a schematic diagram of an embodiment of the testing equipment provided by the present invention. The intelligent device 30 includes a processor 31 and a memory 32. The processor 31 is coupled to the memory 32. The memory 32 stores a computer program, which the processor 31 executes during operation to implement the method described above. Detailed steps can be found above and will not be repeated here.

[0091] Please see Figure 8 , Figure 8 This is a schematic diagram of an embodiment of the computer-readable storage medium provided by the present invention. The computer-readable storage medium 40 stores at least one computer program 41, which is executed by a processor to implement the method described above. Detailed steps can be found above and will not be repeated here. In one embodiment, the computer-readable storage medium 40 can be a storage chip in a terminal, a hard disk, a portable hard disk, a USB flash drive, an optical disc, or other readable and writable storage tools, or it can be a server, etc.

[0092] The storage medium can be implemented by any type of volatile or non-volatile storage device, or a combination thereof. Non-volatile memory can be magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be used as an external cache. The storage media described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable types of memory.

[0093] In the several embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0094] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0095] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0096] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, magnetic disks, and optical disks.

[0097] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a test device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, magnetic disks, or optical disks.

[0098] The methods disclosed in the several method embodiments provided by this invention can be arbitrarily combined without conflict to obtain new method embodiments.

[0099] The features disclosed in the several product embodiments provided by this invention can be arbitrarily combined without conflict to obtain new product embodiments.

[0100] The features disclosed in the several method or device embodiments provided by the present invention can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0101] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various equivalent substitutions or obvious modifications can be made without departing from the concept of the present invention, and all such modifications, achieving the same performance or application, should be considered within the scope of protection of the present invention.

Claims

1. A method for testing read-only memory programs, characterized in that, Applied to the design under test, the design under test includes a test accessor, the test accessor stores a target test program, including at least one write port and at least one read port; The method for testing the program of the read-only memory includes the following steps: Control the at least one write port to be in an unavailable state, and drive the design under test to run the target test program; The target test program is read and run through at least one read port, the running results are obtained, and it is determined whether there are any errors in the target test program based on the running results. If the test program is determined to have an error based on the running results, an updated test program is generated based on the error, the at least one write port is made available, the updated test program is written into the test accessor through the at least one write port, the updated test program is used as a new target test program, the step of making the at least one write port unavailable is executed, and subsequent steps are performed.

2. The method for testing read-only memory programs according to claim 1, characterized in that, Before the step of writing the update test program into the test accessor through the at least one write port, the following steps are included: Reset the design under test to its initial state; After the step of writing the update test program into the test accessor through the at least one write port, the following is included: Release the reset of the design under test, so that the design under test recovers from the initial state.

3. The method for testing read-only memory programs according to claim 1, characterized in that, Prior to the step of controlling the at least one write port to be in an unavailable state, the following steps are included: By using cross-module referencing technology, at least one write port is connected to the outside of the design under test (DUT), enabling the at least one write port to be controlled by a control device outside the DUT, provided that the DUT does not require modification.

4. The method for testing read-only memory programs according to claim 3, characterized in that, After the step of connecting the at least one write port to the outside of the design under test via cross-module referencing technology, the following steps are included: Obtain the compiled project file based on the chip prototype verification platform where the design under test is located and the test requirements, load the project file into the chip prototype verification platform, and run the project file.

5. The method for testing read-only memory programs according to claim 1, characterized in that, After the step of determining whether the test program has errors based on the running results, the following steps are included: If the test program is determined to be error-free based on the test results, then subsequent verification tests will continue.

6. The method for testing a read-only memory program according to claim 1, characterized in that, The at least one write port includes: a write enable port, a write data port, and a write address port; The step of controlling the at least one write port to be in an unavailable state includes: Control the write enable port to the first active level; or The write enable port, the write data port, and the write address port are all controlled to be at the first valid level; The step of controlling the at least one write port to be in an available state includes: Control the write enable port to the second active level; or The write enable port, the write data port, and the write address port are all controlled to be at the second active level.

7. A chip prototype verification platform, characterized in that, A method for running a test read-only memory program according to any one of claims 1-6, comprising: The design under test includes a device under test (DUT) module, which includes a test accessor that stores a target test program and includes at least one write port and at least one read port. A logic control circuit, connected to the at least one write port, is used to control the state of the at least one write port to be available or unavailable. The interface module connects to the logic control circuit at one end and to a test computer outside the design under test at the other end. It is used to receive updated test programs provided by the test computer, so that the updated test programs can be written into the test memory through the logic control circuit.

8. The chip prototype verification platform according to claim 7, characterized in that, When the target test program in the test accessor needs to be verified, the logic control circuit controls the at least one write port to be in an unavailable state. When it is necessary to update the target test program in the test accessor, the logic control circuit controls the at least one write port to be in an available state, so that the updated test program provided by the test computer can be written into the test accessor through the logic control circuit.

9. A computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the steps of the method as claimed in any one of claims 1 to 6.

10. A testing apparatus comprising a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method as claimed in any one of claims 1 to 6.

Images