Verification method, verification system, test device and computing equipment

Abstract

The invention provides an electronic design automation simulation system-on-chip double-rate synchronous dynamic random access memory verification method and verification system, a test device and computing equipment, the method is applied to a startup program, and the method comprises the following steps: obtaining a test case designed according to the characteristics of a double-rate synchronous dynamic random access memory needing to be verified; running a first-stage boot loader; running a second-stage boot loader, and completing initialization of the double-rate synchronous dynamic random access memory; running a third-stage boot loader, loading the test cases in sequence, and carrying out electronic design automation simulation verification; and outputting a verification result through the central processing unit to complete the characteristic verification of the double-rate synchronous dynamic random access memory. According to the technical scheme of the invention, the complexity of DDR verification can be reduced, and high-efficiency DDR verification is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of chip design, and particularly to a verification method and verification system, a test device, and a computing device for a double data rate synchronous dynamic random access memory of a system-on-chip based on an electronic design automation (EDA) simulation system. Background Art

[0002] With the wide application of big data and artificial intelligence, in order to efficiently process massive data, more and more system-on-chip (SOC) chips are integrated with double data rate synchronous dynamic random access memory (DDR) controllers to reduce memory latency. Therefore, verifying the DDR controller of an SOC chip is a key link in the entire SOC chip verification process.

[0003] Currently, the platforms used to verify SOC chips mainly include RTL software simulation verification platforms and FPGA hardware prototype verification platforms. SOC chip verification can be performed based on any of these two platforms. Since the logic of the DDR controller of an SOC chip is relatively complex and there are many test items, the simulation speed on the RTL software simulation verification platform is slow and rapid iteration is not possible, resulting in a longer R & D cycle for SOC chips.

[0004] Most of the existing technologies are based on the FPGA hardware prototype verification platform solution, using FPGAs to piece together an effective process to verify the functions of SOC chips. Since the DDRPHY in an SOC chip is an actual circuit fixed in the SOC chip and cannot be synthesized again, and there may be significant differences between the FPGA DDRPHY and the SOC chip DDRPHY, the FPGA DDRPHY and the SOC chip DDR controller cannot be compatible. Therefore, the current FPGA hardware prototype verification platform usually uses the FPGA DDR controller and the FPGA DDRPHY to replace the SOC chip DDR controller and the SOC chip DDRPHY respectively to perform the verification of the SOC chip. Obviously, the current FPGA hardware prototype verification platform cannot verify the SOC chip DDR controller.

[0005] Therefore, a technical solution is needed that can reduce the complexity of DDR verification and achieve high-efficiency DDR verification. Summary of the Invention

[0006] The present invention aims to provide a verification method and verification system, a test device, and a computing device for DDR of a system-on-chip based on EDA simulation, which can reduce the complexity of DDR verification and achieve high-efficiency DDR verification.

[0007] According to one aspect of the present invention, there is provided a verification method for DDR of a system-on-chip based on an EDA system, characterized in that the method is applied to a startup program and includes:

[0008] Obtain test cases designed according to the double data rate synchronous dynamic random access memory (DDR) characteristics to be verified as needed;

[0009] Run the first-stage bootloader;

[0010] Run the second-stage bootloader to complete the initialization of the double data rate synchronous dynamic random access memory;

[0011] Run the third-stage bootloader, sequentially load the test cases, and perform electronic design automation (EDA) simulation verification;

[0012] Output the verification result through the central processing unit to complete the verification of the double data rate synchronous dynamic random access memory (DDR) characteristics.

[0013] According to some embodiments, the method further includes:

[0014] Write the first-stage bootloader into the read-only memory (ROM) through the verification environment backdoor: write the boot code of the central processing unit (CPU) startup code into the read-only memory through the verification environment backdoor, and the read-only memory is read and executed in the first-stage bootloader.

[0015] According to some embodiments, the last instruction of the first-stage bootloader is a jump address to the static random access memory (SRAM).

[0016] According to some embodiments, the method further includes: write the double data rate synchronous dynamic random access memory training program into the static random access memory (SRAM) of the second-stage bootloader.

[0017] According to some embodiments, the method further includes:

[0018] Before the bootloader starts, initialize the memory controller so that the memory controller can access all memory regions inside the system-on-chip (SOC).

[0019] According to some embodiments, after initializing the memory controller, it further includes:

[0020] Test whether the memory of the double data rate synchronous dynamic random access memory works properly;

[0021] Set the protection mechanism of the memory controller to prevent illegal access and damage to the memory.

[0022] According to some embodiments, after setting the protection mechanism of the memory controller, it further includes:

[0023] Prepare the memory so that the first bootloader can load the boot code of the central processing unit (CPU) startup code into the memory.

[0024] According to another aspect of the present invention, there is provided a computer program product, including: a computer program which, when executed by a processor, implements the verification method described in any one of the above. According to another aspect of the present invention, there is provided a test device for a system-on-chip double data rate synchronous dynamic random access memory. When the test device runs, it executes the verification method described in any one of the above.

[0025] According to another aspect of the present invention, there is provided a computing device, including:

[0026] a processor; and

[0027] a memory storing a computer program which, when executed by the processor, causes the processor to execute the verification method described in any one of the above.

[0028] According to another aspect of the present invention, there is provided a non-transitory computer-readable storage medium having stored thereon computer-readable instructions which, when executed by a processor, cause the processor to execute the method described in any one of the above.

[0029] According to an embodiment of the present invention, by combining a multi-stage bootloader and customized test cases, various characteristics of the DDR memory in the SOC are effectively verified, ensuring the correctness of DDR initialization; compared with the prior art where DDR training is performed in the third-stage bootloader, moving the DDR training to the startup of the second-stage bootloader greatly shortens the time required for simulation and accelerates the verification of DDR function points; using an EDA simulation tool, problems can be discovered in advance without relying on physical hardware, thereby accelerating the development cycle and improving product quality.

[0030] It should be understood that the above general description and the following detailed description are only exemplary and do not limit the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments.

[0032] Figure 1 Shows a flowchart of a verification method for system-on-chip DDR based on EDA simulation according to an exemplary embodiment.

[0033] Figure 2 Shows a schematic diagram of a verification method for system-on-chip DDR based on EDA simulation according to an exemplary embodiment.

[0034] Figure 3 A block diagram of a computing device according to an exemplary embodiment is shown. DETAILED DESCRIPTION

[0035] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. Like reference numerals refer to like or similar parts throughout the figures, and thus their repetitive description will be omitted.

[0036] In addition, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of the embodiments of the present invention. However, those skilled in the art will realize that the technical solutions of the present invention may be practiced without one or more of the specific details, or may be implemented using other methods, components, devices, steps, etc. In other cases, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the present invention.

[0037] The block diagrams shown in the figures are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0038] The flowcharts shown in the figures are merely illustrative and do not necessarily include all of the content and operations / steps, nor do they necessarily have to be executed in the order described. For example, some operations / steps may be decomposed, while some operations / steps may be combined or partially combined, so the actual execution order may change according to the actual situation.

[0039] It should be understood that although terms such as first, second, and third may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Thus, the first component discussed below may be referred to as the second component without departing from the teachings of the concept of the present invention. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0040] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present invention are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or reject.

[0041] Those skilled in the art can understand that the drawings are only schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing the present invention. Therefore, they cannot be used to limit the protection scope of the present invention.

[0042] With the wide application of big data and artificial intelligence, in order to efficiently process massive data, more and more system-on-chip (SOC) chips are integrated with DDR controllers to reduce memory latency. Therefore, verifying the DDR controller of the SOC chip is a key link in the entire SOC chip verification process. Since SOCs are diverse, the startup processes of different SOCs are different, but most SOCs follow a basic process: Power-on reset: After the chip is powered on, all registers and memories are reset to the initial state; BOOT stage: Initialize the hardware; Operating system startup: The kernel is initialized, drivers are loaded, and the file system is mounted; User space initialization: Start system services and the user interface. The DDR controller starts working at the BOOT stage, that is, the verification of DDR in the SOC is mainly also at the BOOT stage. Taking the ARM CPU as an example, the CPU startup system BOOT is divided into three steps. The first-stage bootloader: The bootloader, that is, the bootromcode, will select which way to start the system (EMMC, UART, SPI, etc.). After the first-stage bootloader is executed, it will jump to the second-stage bootloader. The second-stage bootloader: Used for hardware initialization, such as initializing the clock, interrupt, watchdog, etc. This code is executed in the SRAM. After this is executed, it will jump to the third-stage bootloader. The third-stage bootloader: Based on the DDR chip verification of the SOC chip, DDR initialization is usually performed in the third-stage bootloader to perform DDR-related verification.

[0043] The current platforms used to verify SOC chips mainly include the RTL software simulation verification platform and the FPGA hardware prototype verification platform. SOC chip verification can be carried out based on either of these two platforms. Due to the large logic of the SOC chip's DDR controller and the numerous test items, the simulation speed on the RTL software simulation verification platform is slow and rapid iteration is not possible, resulting in a longer R & D cycle for SOC chips.

[0044] To overcome the defects existing in the above-mentioned prior art, the present invention provides a verification method, a verification system and a computing device for the DDR of an EDA simulation system-level chip, which can reduce the complexity of DDR verification and achieve high-efficiency DDR verification. According to the embodiment, by combining a multi-stage bootloader and customized test cases, various characteristics of the DDR memory in the SOC are effectively verified, ensuring the correctness of DDR initialization; compared with performing DDR training in the third-stage bootloader in the prior art, moving the DDR training to the start of the second-stage bootloader greatly shortens the time required for simulation and accelerates the verification of DDR function points; by using EDA simulation tools, problems can be discovered in advance without relying on physical hardware, thereby accelerating the development cycle and improving product quality.

[0045] Before describing the embodiments of the present invention, some terms or concepts related to the embodiments of the present invention are explained.

[0046] A Field-Programmable Gate Array (FPGA) is a programmable integrated circuit that users can program according to their needs to implement specific logic functions. FPGAs have high flexibility and reconfigurability in hardware design and development and are widely used in various fields, including digital signal processing, communication systems, image processing, embedded systems, and high-performance computing, etc.

[0047] A DDR controller (Double Data Rate Controller) is a hardware component responsible for managing DDR (Double Data Rate) memory. DDR memory is a high-performance dynamic random access memory (DRAM) that can transfer data on both the rising and falling edges of each clock cycle, thereby achieving a transmission rate twice that of traditional SDRAM. The DDR controller plays a crucial role in a System on Chip (SOC), responsible for initializing, configuring, and managing the DDR memory to ensure its efficient and reliable operation.

[0048] DDR PHY (Physical Layer) is the physical layer interface in the DDR memory system, responsible for high-speed data transmission between the SOC (System on Chip) and the DDR memory. The main task of the DDR PHY is to ensure the accuracy and integrity of data during high-speed transmission. It usually includes multiple sub-modules, each responsible for a different function.

[0049] The following will illustrate the exemplary embodiments of the present invention with reference to the accompanying drawings.

[0050] Figure 1 The flowchart of a verification method for DDR of a system-on-chip based on EDA simulation according to an exemplary embodiment is shown.

[0051] See Figure 1 , a verification method for DDR of a system-on-chip based on EDA simulation is shown in the figure. The method is applied in the startup program and includes:

[0052] In S101, obtain test cases designed according to the DDR characteristics to be verified.

[0053] According to some embodiments, to obtain test cases designed according to the DDR characteristics to be verified, generally, designers will design a series of targeted test cases according to the specific DDR characteristics to be verified (such as: timing parameters, read and write operations, power management, etc.). The test cases need to cover as many actual usage scenarios as possible and can effectively detect possible problems in the DDR controller.

[0054] In S103, run the first-stage bootloader.

[0055] According to some embodiments, the first step in the startup process is to execute the code in the Bootrom, that is, the first-stage bootloader. The main task of this stage is to load the second-stage bootloader from a predefined startup source (such as EMMC, UART, SPI, etc.) into the internal SRAM.

[0056] In S105, run the second-stage bootloader to complete DDR initialization.

[0057] According to some embodiments, the second-stage bootloader is responsible for the preliminary initialization of the hardware, including but not limited to configuring the clock tree, initializing peripherals, and most importantly, initializing the DDR SDRAM controller. In this step, the DDR controller will be set to a state where it can normally access the external DDR memory. Compared with performing DDR training in the third-stage bootloader in the prior art, moving the DDR training to the startup of the second-stage bootloader greatly shortens the time required for simulation and accelerates the verification of DDR function points.

[0058] In S107, the third-level bootloader is run to load the test cases in sequence for EDA simulation verification.

[0059] According to some embodiments, after the DDR is successfully initialized, the third-level bootloader is run. At this time, the high-level language code (such as C / C++) written by the user starts to execute, which contains the previously designed test cases. These test cases simulate the entire process through an EDA tool to simulate data interaction in a real application scenario, thereby verifying various characteristics of the DDR, enabling developers to observe and analyze the behavior of the DDR in a virtual environment without relying on a physical prototype. Potential problems of the DDR can be discovered earlier through EDA simulation, and the test scheme can be quickly iterated under different hypothetical conditions.

[0060] In S109, the verification result is output through the central processing unit (CPU) to complete the DDR characteristic verification.

[0061] According to some embodiments, finally, the central processing unit (CPU) processes the collected data and outputs the verification result through various interfaces (such as serial port, USB, network, etc.). If all tests pass, it indicates that the DDR controller and related circuits meet the design requirements; otherwise, it may be necessary to return to the design or implementation stage for adjustment.

[0062] According to some embodiments, the design solution of the present invention combines actual hardware testing and EDA simulation, which can not only ensure the accuracy of DDR characteristics, but also accelerate the development cycle and reduce risks. In addition, since the test is carried out in the startup program, potential problems can be identified at an early stage, thereby improving the reliability of the product.

[0063] Figure 2 A schematic flowchart of a method for verifying a system-on-chip DDR based on EDA simulation according to an exemplary embodiment is shown.

[0064] See Figure 2, The figure shows a verification method flow for DDR of a system-on-chip (SOC) based on an EDA simulation. Since there are various SOCs, the startup processes of different SOCs are different, but most SOCs follow a basic process: Specifically, first, power-on reset the test device to initialize the hardware, so that all registers and memories are reset to their initial states. When the SOC chip comes back from tape-out, it cannot be directly powered on and used. It needs to be power-on reset, and then the SOC is configured to enter the normal working state before normal programs and tasks can be run. This is a relatively complex process and is also an important issue that needs to be considered in the SOC design phase. If the power-on fails, the chip cannot be started directly after tape-out, which is also the most significant failure. Therefore, ensuring that the chip can be powered on and started normally is the most important first step in SOC design.

[0065] After that, execute the first-level bootloader, execute the boot ROM code in it, and initialize the basic hardware components. Write the first-level bootloader to the ROM through the backdoor of the verification environment: Write the boot code of the CPU startup code to the read-only memory through the backdoor of the verification environment. The read-only memory is read and executed in the first-level bootloader. Since the ROM space is very small, it is not very realistic to put the entire code in the ROM. Therefore, the CPU startup code is put into the ROM, and the ROM is used to store the boot code, that is, the Bootrom code (the first-level bootloader). The last instruction of the first-level bootloader is the jump address to the static random access memory (SRAM). Assume that we are going to jump to the SRAM for the second-level bootloader. In the first-level bootloader, only the clock of the SRAM needs to be provided and the reset of the SRAM needs to be released, and then the first-level bootloader is jumped to the position of the SRAM, that is, an external storage device (such as EMMC, UART, SPI, etc.) loads the second-level bootloader into the internal SRAM. Write the first-level bootloader program to the ROM through the backdoor of the verification environment.

[0066] Then, write the DDR training program into the static random access memory (SRAM) of the second-stage bootloader. Prepare the second-stage bootloader: Generally, the space of the chip's SRAM is large enough to put the code required for DDR training. The second-stage bootloader only needs to write the DDR training program and then wait for the training to complete and jump to the DDR. Specifically, initialize the minimum hardware environment to ensure that the basic hardware environment can support subsequent operations. Configure and initialize the memory subsystem DDR, set the basic parameters of the DDR controller, including timing parameters, refresh cycle, etc., and make the DDR enter the normal working mode.

[0067] Then, write the second-stage bootloader program into the SRAM through the verification environment backdoor. Prepare the third-stage bootloader. At this time, the chip has completed the initialization of the DDR. Prepare the tests for verifying the characteristics of the DDR, such as: address space traversal, data arbitration, data correctness verification, cache coherence verification and other test programs, and write them into the DDR according to different test cases for sequential verification. As shown in the figure, boot the loader related to DDR verification to execute: Test DDR characteristic 1: Run the first test case to verify a specific DDR characteristic; Test DDR characteristic 2: Run the second test case to verify another DDR characteristic; Test DDR characteristic 3: Run the third test case to verify the third DDR characteristic. After the characteristic verification and comparison, the result is output and printed through the CPU to complete the verification of this feature point.

[0068] According to some embodiments, during the whole process, use EDA tools to simulate the above steps to ensure the correctness and stability of each stage. The simulation tests include but are not limited to: signal integrity analysis: check the quality of signals during transmission; timing analysis: ensure that all signals are within the correct timing window; functional verification: verify the function of the DDR by simulating the actual application scenario. Finally, output the verification result through the central processing unit (CPU) to complete the verification of the DDR characteristics. Such a design scheme can ensure the correctness and reliability of the DDR controller and its related circuits in the SOC, thereby improving the overall performance and stability of the product.

[0069] According to some embodiments, before the bootloader starts, initialize the memory controller so that it can access all memory areas inside the system-on-chip (SOC). Before the bootloader starts, it is necessary to initialize the memory controller so that it can access all memory areas inside the SOC. This step is usually completed by the startup code. The startup code needs to set various registers of the memory controller, including information such as the address mapping table, timing parameters, and memory size.

[0070] According to some embodiments, after initializing the memory controller, test whether the DDR memory is working properly. After initialization is completed, it is necessary to test whether the memory is working properly. This step is usually completed using some simple test programs, such as: filling the memory, reading the memory, etc. Set the protection mechanism of the memory controller to prevent illegal access and damage to the memory. After the test is completed, various protection mechanisms of the memory controller need to be set, such as memory latches, memory permissions, etc., to prevent illegal access and damage to the memory, which can not only ensure the normal operation of the DDR memory, but also effectively prevent the risks of illegal access and damage to the memory, thereby enhancing the reliability and security of the entire system.

[0071] According to some embodiments, after setting the protection mechanism of the memory controller, prepare the memory so that the first boot loader can load the boot code of the CPU startup code into the memory. After setting the memory protection, it is necessary to prepare the memory so that the boot program can load the startup code into the memory. This step usually involves operations such as allocating memory space and setting memory addresses. Effectively preparing the memory environment enables the first-stage boot loader to smoothly load the boot code of the CPU startup code into the memory and start executing safely, which not only ensures the stability of the startup process, but also lays a good foundation for subsequent operating system loading and other tasks.

[0072] According to some embodiments, the method of the present invention can also be applied to the design of a computer program product. When the computer program is executed by a processor, it implements the verification method described in any one of the above. Through the third-stage boot loader, load the test cases in sequence for EDA simulation verification, and then output the verification results through the central processing unit (CPU) to complete the DDR characteristic verification. By combining the multi-stage boot loader and customized test cases, various characteristics of the DDR memory in the SOC can be effectively verified.

[0073] According to some embodiments, the method of the present invention can also be applied to a test device for the DDR of a system-on-chip. When the test device runs, it executes the method described in any one of the above, so as to be able to reduce the complexity of DDR verification and achieve high-efficiency DDR verification.

[0074] According to some embodiments, the design solution of the present invention effectively verifies various characteristics of the DDR memory in the SOC by combining the multi-stage boot loader and customized test cases, ensuring the correctness of DDR initialization; compared with the prior art in which DDR training is performed in the third-stage boot loader, moving the DDR training to the start of the second-stage boot loader greatly shortens the time required for simulation and accelerates the verification of DDR function points; using EDA simulation tools, problems can be discovered in advance without relying on physical hardware, thereby accelerating the development cycle and improving product quality.

[0075] Figure 3 A block diagram of a computing device according to an exemplary embodiment of the present invention is shown.

[0076] As Figure 3 shown, the computing device 30 includes a processor 12 and a memory 14. The computing device 30 may further include a bus 22, a network interface 16, and an I / O interface 18. The processor 12, the memory 14, the network interface 16, and the I / O interface 18 may communicate with each other via the bus 22.

[0077] The processor 12 may include one or more general-purpose CPUs (Central Processing Unit), microprocessors, or application-specific integrated circuits, etc., for executing relevant program instructions. According to some embodiments, the computing device 30 may further include a high-performance display adapter (GPU) 20 for accelerating the processor 12.

[0078] The memory 14 may include a machine system-readable medium in the form of volatile memory, such as random access memory (RAM), read-only memory (ROM), and / or cache memory. The memory 14 is used to store one or more programs containing instructions and data. The processor 12 may read the instructions stored in the memory 14 to execute the method according to the embodiments of the present invention described above.

[0079] The computing device 30 may also communicate with one or more networks via the network interface 16. The network interface 16 may be a wireless network interface.

[0080] The bus 22 may include an address bus, a data bus, a control bus, etc. The bus 22 provides a path for exchanging information between the components.

[0081] It should be noted that in the specific implementation process, the computing device 30 may further include other components necessary for normal operation. In addition, those skilled in the art can understand that the above devices may also only include the components necessary to implement the solutions of the embodiments of this specification, and do not necessarily include all the components shown in the figure.

[0082] The present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the steps of the above method are implemented. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), network storage devices, cloud storage devices, or any type of medium or device suitable for storing instructions and / or data.

[0083] An embodiment of the present invention further provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. The computer program is operable to cause a computer to execute some or all of the steps of any one of the methods described in the foregoing method embodiments.

[0084] Those skilled in the art can clearly understand that the technical solutions of the present invention can be implemented by means of software and / or hardware. The "units" and "modules" in this specification refer to software and / or hardware that can complete specific functions independently or in cooperation with other components. The hardware can be, for example, a field programmable gate array, an integrated circuit, etc.

[0085] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, some steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0086] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0087] In several embodiments provided by the present invention, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some service interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical or other form.

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

[0089] In addition, in each embodiment of the present invention, each functional unit may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of a software functional unit.

[0090] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer-readable memory. Based on such understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, may be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of the present invention.

[0091] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0092] The above specifically shows and describes the exemplary embodiments of the present invention. It should be understood that the present invention is not limited to the detailed structures, setting manners, or implementation methods described herein; on the contrary, the present invention is intended to cover various modifications and equivalent settings included within the spirit and scope of the appended claims.

Claims

1. A verification method for a double rate synchronous dynamic random access memory of a system-level chip based on electronic design automation simulation, characterized in that: The method is applied in a startup program, and includes: Obtain test cases designed according to the double rate synchronous dynamic random access memory characteristics that need to be verified; Run the first-stage boot loader; Run the second-level boot loader to complete the double-rate synchronous dynamic random access memory initialization; Running the third-level boot loader, loading the test cases in sequence, and performing electronic design automation simulation verification; The verification results are output by the central processing unit to complete the double-rate synchronous dynamic random access memory characteristic verification.

2. The verification method according to claim 1, characterized in that: Also includes: Writing the first-level boot loader into the read-only memory through the verification environment backdoor: writing the boot code of the central processing unit startup code into the read-only memory through the verification environment backdoor, and the read-only memory is read and executed in the first-level boot loader.

3. The verification method according to claim 2, characterized in that: The last instruction of the first-level boot loader is a jump address to the static random access memory.

4. The verification method according to claim 1, characterized in that: Also includes: The DDRSDRAM training program is written into the SRAM of the second-level boot loader.

5. The verification method according to claim 1, characterized in that: Also includes: Before the boot program starts, the memory controller is initialized so that the memory controller can access all memory areas inside the system-level chip.

6. The verification method according to claim 5, characterized in that: After initializing the memory controller, it also includes: Testing whether the memory of the double rate synchronous dynamic random access memory is working properly; Set up a protection mechanism for the memory controller to prevent illegal access and memory damage.

7. The verification method according to claim 5, characterized in that: After setting up the memory controller protection mechanism, it also includes: The memory is prepared so that the first boot loader loads the boot code of the CPU startup code into the memory.

8. A computer program product, characterized in that include: A computer program, wherein when the computer program is executed by a processor, the verification method according to any one of claims 1 to 7 is implemented.

9. A system-on-chip double rate synchronous dynamic random access memory test device, characterized in that: When the testing device is running, the verification method according to any one of claims 1 to 7 is executed.

10. A computing device, characterized in that: include: processor; as well as A memory storing a computer program, which, when executed by the processor, enables the processor to perform the verification method according to any one of claims 1 to 7.

Images