A test method and system for processor system-level design

Abstract

The present invention provides a test method and system for processor system-level design, comprising: a processor test platform based on SoC‑FPGA selects a memory and peripheral usage mode of a processor under test according to hardware source code and device conditions, detects the processor to be tested and performs interface standardization processing on it, and divides the interface of the processor to be tested according to function; the processor test platform deploys the processor to be tested in the form of a soft core in combination with the selected memory and peripheral usage mode, designs an address space mapping mechanism between a hard-core processor and the processor to be tested, constructs an FPGA project and generates a hardware configuration file; compiles the software source code and generates a software load for testing; the hard-core processor deploys the software load according to the selected memory and peripheral usage mode; provides the peripheral interface resources of the SoC‑FPGA to the processor to be tested in an exclusive or shared manner according to the memory and peripheral usage mode; and executes the software load to evaluate the complete hardware and software system.

Description

Technical Field

[0001] The present invention relates to prototype testing of computer chips, and in particular to the technical field of processor system-level testing. Background Art

[0002] In the early stages of the processor design and development process, the development and testing of related system software requires a stable hardware prototype, which leads to seriality between hardware and software development and reduces the overall development and iteration efficiency. In order to shorten the development cycle, the software-hardware collaborative design method that divides the system functions into software and hardware at the beginning of the design is widely adopted, allowing the development of software and hardware to proceed in parallel, and integrating software and hardware in the testing phase to carry out collaborative testing. Software-hardware collaborative testing shortens the testing time by building a relatively realistic hardware simulation environment to be tested under the test framework and running the software to be tested on it, while observing the software and hardware behaviors during the operation process. At the same time, the software load to be tested includes two scenarios. For the test scenario without an operating system, it should cover the bare metal test program; for the scenario that needs to be tested based on the operating system, it should cover the boot firmware, operating system, application and other user-mode applications; and form a relatively complete software stack for different scenarios. As the scale of hardware design becomes more complex, each level of the software stack needs to track the version adjustments of various hardware interfaces (clock and reset logic, memory access interface, various external communication devices, etc.) for timely adaptation, which poses a challenge to the comprehensive software load management and maintenance during the processor chip prototype testing process.

[0003] In summary, the processor design team needs a prototype test system with complete software and hardware integration so that the software and hardware codes can be modified as needed during the development process and integrated testing can be performed. System-level testing mainly uses the method of emulating or simulating the entire software and hardware. Among them, building a prototype system based on FPGA (Field Programmable Gate Array) is a full-system simulation method widely used in the industry. In recent years, the reduction in FPGA costs and the increase in scale, as well as the similar characteristics of FPGA and real hardware logic circuits, have made the advantages of FPGA-based prototype testing more and more obvious.

[0004] With the continuous development and maturity of the integrated circuit industry, some typical basic logic function modules inside the processor have gradually stabilized after multiple tape-out verifications, and the possibility of large-scale logic errors and design defects in these basic modules in the future has been greatly reduced. However, current processors integrate more and more basic module components. As the overall complexity of the system continues to increase, in the future, not only will the workload of simulation testing for traditional RTL (register transfer logic) logic design descriptions and gate-level circuits continue to decrease, but a platform and method for quickly building software and hardware prototypes will be needed to carry out system-level prototype testing as soon as possible.

[0005] There are already some related projects at home and abroad for testing of processor system-level design. For example, in the field of RISC-V research, a specific RISC-V core, Rocketchip, is deployed to traditional general-purpose FPGA devices to provide designers with a typical RISC-V SoC reference system. Although its open source code repository provides some simple I / O interface usage methods, the interface types and functions are extremely limited and cannot meet the complete testing requirements of the target processor hardware and software system. In addition, the I / O interface it provides can choose to use the IP provided in the Xilinx FPGA development tool, but these IP cores still need to be deployed on the FPGA in the form of logic circuits, occupying the logic resources required by the processor to be tested.

[0006] Another example is building an open source research platform for heterogeneous SoC design. It is highly scalable and provides platform customization capabilities and interfaces. It improves the abstraction level of system-level design and supports the automation process from software and hardware development to full-system prototypes on FPGAs. It focuses on automated solutions for accelerators in specific fields, quickly generates accelerators through high-level synthesis methods, and maps complex workloads to SoC architectures.

[0007] The existing technology also includes using the hard-core processor part of SoC-FPGA to capture the peripheral address access request initiated by the processor to be tested, and transferring the corresponding data generated by the RISC-V processor accessing the peripheral controller through the AXI peripheral control bus, and finally printing it through the serial port. However, the method provided can only collect relevant access data records of the peripheral access path of the processor to be tested, and cannot meet the testing requirements of the complete hardware and software system. The real-time performance is poor, and it also does not consider the support of complex peripheral access methods such as DMA.

[0008] The above-mentioned software and hardware collaborative test system basically still uses the traditional general-purpose FPGA device without hard core, with the goal of providing large-capacity programmable logic resources. The design process mainly uses the EDA (Electronics Design Automation) tools provided by the FPGA manufacturer to configure the device, thereby building an FPGA prototype system. The FPGA development process of each manufacturer is basically the same, but the development process often involves complicated details in engineering. In the prototype test based on the traditional general-purpose FPGA, in addition to the processor core to be tested, it is also necessary to implement some basic communication interfaces, including but not limited to DDR3 / 4 memory access interface, network interface, serial port, USB / MMC / SD interface, etc. People without FPGA development experience need a considerable amount of time to learn and master, and the technical threshold is high. In addition, the implementation of these interfaces itself also requires a large amount of on-chip logic resources of the FPGA, thereby squeezing the layout and wiring freedom space of the processor core to be tested, and it is more likely to cause problems such as timing violations. In addition, due to the underlying chip implementation process, compared to the ASIC that has been taped out, the operating frequency of the processor core in the prototype test scenario of the general-purpose FPGA is low, and it often takes a considerable amount of time to execute some computationally intensive tasks. This waiting time will also indirectly affect the processor testing process.

[0009] In summary, the prototype test solution based on traditional general-purpose FPGA has some problems in building complex systems. Due to the inherent defects of the underlying implementation process of traditional general-purpose FPGA chips, compared with application specific integrated circuits (ASICs), the operating frequency of the processor core in the prototype test scenario of general-purpose FPGAs is often lower, and it often takes a considerable amount of time to execute some computationally intensive tasks. These waiting times will also indirectly affect the test process of the processor, and even cause the test link to time out and become stuck. In addition, prototype testing based on general-purpose FPGAs generally requires the construction of a series of peripherals and memory access interfaces for the processor core to be tested. These interfaces require considerable programmable logic resources, squeezing the available resource margin of the processor core to be tested, and also affecting the layout and routing freedom within the FPGA. Summary of the invention

[0010] The present invention is to solve the above-mentioned conventional general-purpose FPGA prototype test solution and propose a test method for processor system-level design, which is characterized by comprising:

[0011] Step 1: Obtain the hardware source code and software source code of the processor to be tested, and select the memory and peripheral usage mode required for the test according to user requirements and device conditions;

[0012] Step 2: The processor test platform based on SoC-FPGA detects the processor to be tested and performs interface standardization processing on it according to the hardware source code, and divides all interfaces of the processor to be tested according to function; the processor test platform combines the memory and peripheral usage mode, deploys the processor to be tested in the form of a soft core to the programmable logic side of the SoC-FPGA, and maps the address space of the processor to be tested to the address space of the SoC-FPGA hard-core processor through a customized logic circuit, so as to realize exclusive or shared use of the hard-core processor memory and peripheral resources;

[0013] Step 3: Build a complete FPGA project and finally generate a hardware configuration file; compile the software source code and generate a software load for testing;

[0014] Step 4: The hard-core processor in the SoC-FPGA assists the startup of the processor to be tested according to the selected memory and peripheral usage mode. The startup content includes: 1. bit stream configuration on the programmable logic side; 2. moving the software load file required in the startup process of the RISC-V processor to be tested to the corresponding memory address space; 3. releasing the reset signal of the RISC-V processor to be tested on the programmable logic side;

[0015] Step 5: After the processor to be tested is started, the software load is obtained and executed. The entire process of starting and executing the processor to be tested uses the memory and peripheral interface resources of the SoC-FPGA exclusively or shared according to the memory and peripheral usage mode.

[0016] The test method for processor system-level design is characterized in that when the processor to be tested needs to read and write sensitive registers of the peripheral interface, the processor to be tested selects to pass the read and write tasks to the platform management unit of the SoC-FPGA for processing through the hardware Mailbox module during operation, which specifically includes:

[0017] The processor to be tested initiates an inter-core interrupt: the processor to be tested is put into the highest privilege mode; the inter-core interrupt parameters are written to the parameter segment of the hardware Mailbox module through the peripheral interface and the inter-core interrupt type is indicated, and the request mark segment of the Mailbox module is marked;

[0018] Transferring the reading and writing tasks of sensitive registers: the hard-core processor processes the inter-core interrupt request according to the request tag segment and the parameter segment, accesses the sensitive registers through the platform management unit, and sends the information result returned by the platform management unit to the Mailbox module; returning the access result: the processor under test reads back the information result from the Mailbox module and clears the mark in the request tag segment.

[0019] The test method for processor system-level design is characterized in that when there is a test load that needs to perform complex calculations during the startup or operation of the processor to be tested, the processor to be tested chooses to communicate with the hard-core processor through the Mailbox module when performing the calculation task, specifically including:

[0020] In the process of executing the computing task, the processor to be tested is put into the highest privilege mode, and the shared memory address where the data to be calculated is located is written to the parameter segment of the Mailbox module through the peripheral interface, and the required auxiliary computing type is indicated, and the request marking segment of the Mailbox module is marked;

[0021] The hard-core processor reads the data to be calculated from the shared memory according to the request marker segment and the parameter segment, performs the calculation task, and writes the calculation result into the shared memory;

[0022] The processor to be tested reads back the calculation result from the shared memory and clears the mark in the request mark segment.

[0023] The test method for processor system-level design is characterized in that the memory and peripheral usage mode is a soft-core exclusive physical resource mode. In the soft-core exclusive physical resource mode, the processor to be tested obtains all peripheral interface resources of the SoC-FPGA, and the hard-core processor only maintains the operation of the service program, which is a program used to assist in starting the processor to be tested.

[0024] The test method for processor system-level design is characterized in that the memory and peripheral usage mode is a physical resource sharing mode between soft and hard cores based on static partitioning. Under the physical resource sharing mode between soft and hard cores based on static partitioning, a part of the peripheral interface resources of the SoC-FPGA is obtained for the processor to be tested, and the hard-core processor, in addition to maintaining the operation of the service program, also performs other tasks through another part of the peripheral interface resources of the SoC-FPGA.

[0025] The test method for processor system-level design is characterized in that the memory and peripheral usage mode is a physical resource sharing mode between soft and hard cores based on dynamic partitioning and virtualization. In the physical resource sharing mode between soft and hard cores based on dynamic partitioning and virtualization, the processor to be tested needs all interface resources on the SoC-FPGA and the hard-core processor needs to perform computing tasks, and the interface peripherals of the SoC-FPGA are virtualized and shared with the hard-core processor and the processor to be tested. The processor to be tested obtains all interface resources on the SoC-FPGA, and the hard-core processor, in addition to maintaining the operation of the service program, also performs other tasks by sharing peripheral interface resources.

[0026] The present invention also proposes a test system designed for a system-level processor, which is characterized by comprising:

[0027] Module 1 is used to obtain the hardware source code and software source code of the processor design to be tested, and select the memory and peripheral usage mode required for the test according to user requirements and device conditions;

[0028] Module 2, for a processor test platform based on SoC-FPGA, detects the processor to be tested and performs interface standardization processing on it according to the hardware source code, and divides all interfaces of the processor to be tested by function; the processor test platform deploys the processor to be tested in the form of a soft core to the programmable logic side of the SoC-FPGA in combination with the memory and peripheral usage mode, and maps the address space of the processor to be tested to the address space of the SoC-FPGA hard-core processor through a customized logic circuit, so as to realize exclusive or shared use of the hard-core processor memory and peripheral resources;

[0029] Module 3 is used to build a complete FPGA project and finally generate a hardware configuration file; compile the software source code and generate a software load for testing;

[0030] Module 4 is used to enable the hard-core processor in the SoC-FPGA to assist in starting the processor to be tested according to the selected memory and peripheral usage mode;

[0031] Module 5 is used to obtain and execute the software load after the processor to be tested is started and runs. The entire process of starting and executing the processor to be tested exclusively or sharedly uses the memory and peripheral interface resources of the SoC-FPGA according to the memory and peripheral usage mode.

[0032] The test system for processor system-level design is characterized in that:

[0033] When the processor under test needs to read and write sensitive registers of the peripheral interface, the processor under test selects to pass the read and write tasks to the platform management unit of the SoC-FPGA through the hardware Mailbox module during operation, which includes:

[0034] The processor to be tested initiates an inter-core interrupt: the processor to be tested is put into the highest privilege mode; the inter-core interrupt parameters are written to the parameter segment of the hardware Mailbox module through the peripheral interface and the inter-core interrupt type is indicated, and the request mark segment of the Mailbox module is marked;

[0035] Transferring the read and write tasks of sensitive registers: the hard-core processor processes the inter-core interrupt request according to the request tag segment and the parameter segment, accesses the sensitive registers through the platform management unit, and sends the information result returned by the platform management unit to the Mailbox module; returning the access result: the processor under test reads back the information result from the Mailbox module and clears the mark in the request tag segment;

[0036] When there is a test load that needs to perform complex calculations during the startup or operation of the processor to be tested, the processor to be tested chooses to communicate with the hard-core processor through the Mailbox module when performing the calculation task, specifically including:

[0037] In the process of executing the computing task, the processor to be tested is put into the highest privilege mode, and the shared memory address where the data to be calculated is located is written to the parameter segment of the Mailbox module through the peripheral interface, and the required auxiliary computing type is indicated, and the request marking segment of the Mailbox module is marked;

[0038] The hard-core processor reads the data to be calculated from the shared memory according to the request marker segment and the parameter segment, performs the calculation task, and writes the calculation result into the shared memory;

[0039] The processor to be tested reads back the calculation result from the shared memory and clears the mark in the request mark segment;

[0040] The memory and peripheral usage mode is a soft-core exclusive physical resource mode. In the soft-core exclusive physical resource mode, the processor to be tested obtains all peripheral interface resources of the SoC-FPGA, and the hard-core processor only maintains the operation of the service program, which is a program used to assist in starting the processor to be tested.

[0041] Or the memory and peripheral usage mode is a physical resource sharing mode between soft and hard cores based on static partitioning. In this physical resource sharing mode between soft and hard cores based on static partitioning, the processor to be tested obtains a part of the peripheral interface resources of the SoC-FPGA. In addition to maintaining the operation of the service program, the hard-core processor also performs other tasks through another part of the peripheral interface resources of the SoC-FPGA.

[0042] Or the memory and peripheral usage mode is a physical resource sharing mode between soft-core and hard-core based on dynamic partitioning and virtualization. In this physical resource sharing mode between soft-core and hard-core based on dynamic partitioning and virtualization, the processor to be tested needs all the interface resources on the SoC-FPGA and the hard-core processor needs to perform computing tasks. The interface peripherals of the SoC-FPGA are virtualized and shared with the hard-core processor and the processor to be tested. The processor to be tested obtains all the interface resources on the SoC-FPGA. In addition to maintaining the operation of the service program, the hard-core processor also performs other tasks by sharing peripheral interface resources.

[0043] The present invention also proposes a storage medium for storing a program for executing any one of the test methods for processor system-level design.

[0044] The present invention also provides a client, which is used for the test system oriented to processor system level design.

[0045] It can be seen from the above scheme that the advantages of the present invention are:

[0046] The test platform and method of the present invention can effectively save on-chip logic resources, alleviate the layout and wiring pressure of the processor core to be tested, and also reduce the iteration cycle of traditional system-level prototype testing, thereby lowering the technical threshold for developers. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 This is a schematic diagram of the prototype verification platform based on SoC-FPGA;

[0048] Figure 2 This is a schematic diagram of prototype verification based on SoC-FPGA;

[0049] Figure 3 Initiate virtual inter-core interrupt requests to the PMU for the Linux driver running on the RISC-V processor;

[0050] Figure 4a To verify the complete startup process of the platform, the left side of the figure shows the execution process of the ARM hard-core processor, and the right side shows the execution process of the RISC-V soft-core processor;

[0051] Figure 4b It is a schematic diagram of the peripheral resource access mode of the verification platform including DMA;

[0052] Figure 5a This is the complete startup process of another verification platform. The left side of the figure shows the execution process of the ARM hard-core processor, and the right side shows the execution process of the RISC-V soft-core processor;

[0053] Figure 5b A schematic diagram of another verification platform peripheral resource access mode including DMA;

[0054] Figure 6a This is the complete startup process of another verification platform. The left side of the figure shows the execution process of the ARM hard-core processor, and the right side shows the execution process of the RISC-V soft-core processor;

[0055] Figure 6b A schematic diagram of another verification platform peripheral resource access mode including DMA;

[0056] Figure 7 This is the process flow of information exchange between the RISC-V processor and the PMU based on Mailbox. The order of the steps is shown in the sequence numbers marked in the figure;

[0057] Figure 8 This is the step-by-step process for the ARM processor to run complex computing tasks in collaboration with RISC-V based on Mailbox. The order of the steps is shown in the serial numbers marked in the figure. DETAILED DESCRIPTION

[0058] When the inventor was studying the test method for the system-level design of RISC-V processors, he found that the defect in the prior art was caused by the inherent defect of the general-purpose FPGA device itself. After investigating the evolution of the existing chip technology, it was found that with the evolution of SoC (System-on-a-Chip) technology, two parts, the programmable logic side and the hard-core processor system side, were integrated on the same chip. The Zynq / ZynqMP series devices launched by AMD / Xilinx include PL (Programmable Logic, conceptually equivalent to a traditional general-purpose FPGA device) and PS (Processing System); and the Stratix 10 launched by Intel (Altera), which also adds HPS (Hard Processor System) design on the basis of traditional general-purpose FPGAs, are both representative SoC-FPGA devices. Whether it is Xilinx's PS or Altera's HPS, they are technically complete SoC systems built on ARM processors, with ASIC-level clock frequency and reliability. For example, taking AMD / Xilinx's Zynq / ZynqMP as an example, its PS side contains ARM processors, PMU (Platform Management Unit) coprocessors, and various standard interface peripheral resources, which can interact with the programmable logic side through the AXI bus. SoC-FPGA can be considered as the complementary technical advantages of ASIC devices and FPGA devices. From the concept of hard core / soft core, the PS side generally uses ASIC technology, and the ARM processors and PMU coprocessors included are hard core processors; the PL side is the programmable logic side, and the RISC-V core deployed on it is a soft core processor.

[0059] In view of the above shortcomings of traditional general-purpose FPGAs in building complex systems, the present invention proposes a basic platform for agile software and hardware collaborative testing of processors based on SoC-FPGA. The platform uses the Zynq / ZynqMP series devices as an implementation example, fully exploring the software and hardware support capabilities of SoC-FPGA devices for system-level prototype testing of target processor software and hardware, and constructs hardware and software infrastructure at all levels on the SoC hard-core processor of the target processor prototype test platform, so that the target processor core to be tested can obtain access rights to the hard-core SoC peripheral interface resources, and use the computing power of the platform's SoC hard-core processor to assist and accelerate key operations generated during the simulation test. Therefore, the overall method of this application includes:

[0060] Step 1: The user submits the hardware and software source code files of the processor design to be tested, and selects one of the three memory and peripheral usage modes based on the test requirements. The hardware source code files mainly include the logic design at the processor level (mainly the hardware description language) and the hardware script code required to build the FPGA project; the software source code files include the software codes of different stages such as the bare metal test program or the boot software, operating system, and application layer executable program.

[0061] Step 2: The processor hardware and software collaborative test platform based on SoC-FPGA obtains the processor hardware source code, performs interface standardization on the processor module, automatically detects and standardizes the three types of interfaces: peripherals / memory access / consistency, and plans the platform's address space in combination with the user's selected memory and peripheral usage mode. Finally, the FPGA project construction is completed and a hardware configuration file is generated for configuring the bitstream file of the FPGA device.

[0062] Step 3: The platform obtains the processor software source code, compiles it and generates a software load for testing, including a bare metal test program or boot software, operating system, application program, etc.

[0063] Step 4: Power on the platform. The platform startup process is slightly different in the three modes. For details, see Figure 6a / 7a / 8a; During the startup of the test platform, the ARM processor completes the platform initialization and boot file loading, and then the control of each peripheral is transferred to the processor to be tested;

[0064] Step 5: After the processor to be tested is started, the corresponding test software is obtained and executed, and the operation information is output through the platform peripherals. In the scenario of testing based on the operating system, the processor to be tested generally only executes the corresponding operating system and application after startup, but for RISC-V, the boot software often includes the SBI interface for running M-MODE operations. The boot software needs to be resident in the memory for call, not abandoned after startup.

[0065] In order to achieve the above technical effects, the present invention relates to the following key technical points:

[0066] Key point 1: We fully exploited the potential of tightly coupled SoC-FPGA devices and built a Mailbox-based information interaction mechanism between the RISC-V soft core and the ARM hard core (SoC side). Based on this information interaction mechanism, we provide the target processor with abundant I / O peripheral resources and establish access methods for basic platform management permissions, so as to quickly build prototype hardware with complete basic functions; at the same time, we fully utilize the computing power of the hard-core ARM processor to coordinate the efficient operation of the target RISC-V processor software system, solve the problem of timeout and freeze, and improve the work efficiency of the platform.

[0067] The system-level processor testing platform and method described in the present invention explore the potential of SoC-FPGA devices and build a set of information interaction mechanisms based on Mailbox between the soft core and hard core (SoC side) of the processor to be tested. The Mailbox module can be directly addressed and accessed by the MMIO interface like ordinary peripherals, providing a way for the processor to be tested on the programmable logic side to indirectly access the platform management unit, and plays an important role in the computing power assistance work of the ARM processor. The platform also integrates various levels of software and hardware involved in the system-level prototype test of the processor core. In terms of hardware, various communication interface IP cores and processor resources on the hard core processing system side of the programmable SoC are reused to support the work of the soft core of the processor to be tested, and as many logic resources as possible are reserved on the programmable logic side to provide services to users. In terms of software, various levels from firmware to Linux kernel are integrated, and service programs designed to assist the startup and operation of the processor to be tested are used, and the startup and operation process of the processor to be tested is assisted by executing the service program on the hard core processing system side.

[0068] Technical effect: It makes up for the defects of traditional general-purpose FPGAs, saves a lot of programmable logic to be reserved for the processor core to be tested, and simplifies the learning cost and technical threshold for system-level testers based on software-hardware collaborative testing.

[0069] Key point 2: Based on key point 1, the platform and method of the present invention "explore the potential of programmable SoC devices", specifically, by multiplexing, utilizing the external communication interface and memory access interface resources on the hard-core processing system side of the SoC-FPGA device, as well as the functional assistance of the platform management unit coprocessor and the computing power acceleration of the hard-core processor, so as to achieve the technical effect described in key point 1;

[0070] Key point 3, based on key point 2, for some SoC-FPGA devices that cannot allow the processor under test on the programmable logic side to directly send inter-core interrupt requests to the platform management unit, an auxiliary forwarding solution based on shared memory is proposed, so that the processor under test can indirectly obtain control permissions such as clock and power management; the technical effect is that the processor under test can obtain access rights to sensitive registers of the I / O interface on the SoC-FPGA. Sensitive registers refer to registers of certain I / O peripherals that have special functions, such as controlling the operating frequency, power supply status, and power consumption status of the I / O peripherals. Modifications to such registers will cause significant changes in the working status of the I / O peripherals. This type of register is called a "sensitive register";

[0071] Key point 4, based on key point 2, for some SoC-FPGA chip platforms with limited physical peripheral resources, there will be a derivative problem that physical peripherals cannot be shared well. To address this problem, the present invention combines different scenario requirements and SoC-FPGA on-chip resource conditions, in order to flexibly adapt to SoC-FPGA models with different configurations and take into account different testing requirements, the platform and method of the present invention provide three memory and peripheral usage modes:

[0072] Mode 1: Soft core exclusively occupies physical resources. In mode 1, when the processor under test needs complete interface resources on the SoC-FPGA, a memory and peripheral usage mode is proposed, which is mainly based on the processor under test on the programmable logic side and supplemented by the hard core processing system side (the processor under test obtains all the interface resources of the SoC-FPGA chip, and the hard core processing system side only maintains the service program running);

[0073] Mode 2: Physical resource sharing between soft-core and hard-core based on static partitioning. In this mode, when the processor under test does not need all the interface resources on the SoC-FPGA, but the hard-core processing system needs to perform more complex tasks, a mode of equal memory and peripheral usage between the processor under test on the programmable logic side and the hard-core processing system side is proposed (each side occupies a set of physical peripheral resources, and the functions do not affect each other);

[0074] Mode 3: Physical resource sharing between soft-core and hard-core based on dynamic partitioning and virtualization methods. In this mode, if the processor under test needs all the interface resources on the SoC-FPGA and the hard-core processing system needs to perform more complex tasks, a peer-to-peer memory and peripheral usage mode between the processor under test on the programmable logic side and the hard-core processing system side is proposed if the SoC-FPGA device can support interface peripheral virtualization (both sides are isolated and share the same set of logic peripheral resources);

[0075] The present invention finely divides the address space of the system-level test platform SoC-FPGA chip, and adjusts the startup schemes of the processor cores on both sides of the platform hard-core processor and the target test processor respectively, to achieve the working effects of the three modes mentioned above. The above method can effectively avoid access conflicts when the processor to be tested and the hard-core processor concurrently access the memory and peripheral interface on the test platform as a whole;

[0076] In order to make the above features and effects of the present invention more clearly and understandably explained, the following embodiments are specifically cited, and detailed descriptions are given in conjunction with the drawings of the specification as follows. The platform and method described in the present invention are generally applicable to various instruction set processors; similarly, the SoC-FPGA mentioned in the present invention, its hard-core processor is not limited to ARM processors, as long as it is a hard-core processor manufactured by ASIC technology. Considering that the hard core of the current SoC-FPGA device is basically the ARM instruction set, and the research on the processor of the RISC-V instruction set is relatively active, the specific implementation case can be represented by Xilinx's Zynq / ZynqMP as the representative of the SoC-FPGA device, and RISC-V as the soft core of the processor to be tested as a typical case to explain the implementation details. In order to facilitate the combination of actual scenarios and more clearly interpret the technical ideas of the platform and method described in the present invention, the methods described in the specific implementation method part of the present invention are all described with the Zynq7000 / ZynqMPSoC series devices launched by AMD (Xilinx) as typical cases, but the platform and method described in the present invention are not limited to devices of a specific manufacturer, and can be widely used in SoC-FPGA device scenarios.

[0077] PS side reuses external communication interface and memory access interface resources. Complete CPU testing requires frequent interactions between the core to be tested and various peripheral interfaces. Some specific test data also needs to be input into the processor to be tested through related peripheral interfaces, and the test results are output through the peripheral interfaces. SoC-FPGA integrates many common networks, SDIO (Secure Digital Input and Output), USB, UART (Universal Asynchronous Receiver / Transmitter), PCIe, DDR memory controller and other external interfaces into a hard core. Making full use of these hard core interfaces can bring convenience to prototype testing. In the test platform framework (such as Figure 1 As shown), the present invention connects the MMIO interface of the PL processor to be tested to the PS end, and allows the processor to be tested to access various communication interfaces of the PS end.

[0078] like Figure 1As shown in the figure, the RISC-V soft-core processor to be tested is located on the programmable logic side, and can access the memory and I / O peripheral resources on the ARM hard-core SoC side through different types of bus interfaces (memory access interface and peripheral interface); at the same time, the I / O peripherals can initiate DMA access to the RISC-V visible memory through the consistency interface. In addition, in order to improve the compatibility of the test platform at all levels of software and hardware, this paper proposes a test platform design framework for software and hardware collaboration based on the Mailbox module. Through the shared access of the RISC-V soft core and the ARM hard core to the Mailbox module, efficient collaboration of the hard-core processor with the RISC-V processor software and hardware testing is achieved. Figure 1 As shown in the test platform framework, the RISC-V processor core to be tested mainly includes three types of bus interfaces, namely memory access interface, consistency interface and peripheral interface, among which the peripheral interface generally works in memory-mapped I / O (MMIO) mode.

[0079] The processor under test accesses the DDR controller on the PS side through the memory access interface. Some peripheral devices with a large amount of communication data, such as SDIO and Ethernet, also have DMA (Direct Memory Access) interfaces connected to the cache consistency interface of the processor under test. Fully explore all types of communication interfaces. The MMIO interface also provides a way for the processor under test on the PL side to indirectly access the PMU. The above sensitive registers are not allowed to be directly accessed by general-purpose processors. General-purpose processors are required to wake up the platform management unit PMU through inter-core interrupts, access these sensitive registers through the firmware program running on the PMU, and transmit the results back to the general-purpose processor.

[0080] The UART, SDIO, network and other peripherals in the PS can be accessed by the processor under test in the PL through the above interfaces, and can also be accessed by the ARM processor in the PS. During the startup of the test platform, the ARM processor first completes the platform initialization and boot file loading, and then the control of each peripheral is transferred or shared to the processor under test to achieve the reuse of peripheral resources. The usage of each peripheral resource during the platform startup process is as follows:

[0081] UART: During the startup of the test platform, the log information of each startup stage of the ARM processor and the processor under test, as well as the interaction after the file system is mounted, can be input and output through the UART interface.

[0082] SDIO: In SD card based boot mode, both ARM and PUT boot files need to be moved from SD card to memory. After booting the Linux kernel, the PUT also needs to install the Debian file system on the SD card partition, all of which require an SDIO channel. Considering that the SDIO occupation time of ARM and PUT does not overlap during boot and run, only one SDIO interface is required on the PS side.

[0083] Network: In the network-based TFTP boot mode, both the ARM and the processor under test boot files need to be moved from the remote end of the network to the memory. After booting the Linux kernel, the processor under test also needs to mount the Debian file system on the NFS server, which requires a network interface channel. Considering that the ARM and the processor under test do not occupy the same network interface time during boot and operation, only one network interface on the PS side is required.

[0084] If you do not choose to use the various peripheral interface resources on the PS end, the interface required for testing the processor to be tested usually needs to be implemented directly on the FPGA. For some high-speed interfaces, even if a reliable IP core provided by Xilinx or a third-party company is used, the implementation of the interface itself also requires a large amount of logic resources. The test platform saves these potential logic resource costs. Especially for large-scale processor testing, the method proposed by the present invention can indirectly reduce the layout and wiring pressure when deploying the processor to be tested.

[0085] The interface of the RISC-V processor to be tested is standardized. Processor testing needs to work in an environment close to the real environment, and different RISC-V processors may have bus interfaces with different names and numbers. In order to quickly deploy the RISC-V processor to be tested in the test platform, it is necessary to standardize the interface of the RISC-V processor. The present invention provides a processing step for standardizing the processor bus interface. When the user submits the HDL code of the processor to be tested, the platform will execute the following steps: Figure 2 The processing flow shown automatically detects and standardizes the processing of three types of interfaces: peripherals / memory access / cache consistency, and finally completes the FPGA project construction work.

[0086] The PMU coprocessor assists in its functions and the ARM processor assists in its computing power. The PS-side processor core mainly consists of two parts: the ARM main processor and the PMU coprocessor. As the high-performance main processor core of the PS terminal, the ARM core has a high main frequency and starts working immediately after power-on. It can directly access memory and read and interact with various peripheral interfaces. The PMU is a hard-core processor that performs management functions on the SoC-FPGA. The PMU can perform operations that are not allowed on other processors, such as power management, clock management, and PL configuration.

[0087] Functional assistance. The Linux running on the processor under test in the PL needs to access peripheral controllers such as UART, SD card, and Ethernet in the PS. The drivers of these peripheral devices need to control the clocks of the corresponding peripheral devices, and these peripheral devices can only be managed by the PMU. The processor under test needs to interact with the PMU to fully access and control various peripheral devices on the PS side, so it is necessary to establish a communication mechanism between the processor under test and the PMU. The processor under test writes the IPI (Inter-Processor Interrupt) message to the specified physical memory address (which can be part of the DDR memory space or the on-chip memory on the PL side) in MMIO mode, which is received by the service program on the ARM processor in a polling manner, and the IPI request message is forwarded to the PMU to complete the requested operation.

[0088] The service program has the following two major functions. The first is to assist in the startup of the RISC-V processor to be tested, including 1. bitstream configuration on the programmable logic side; 2. moving the software load files required during the startup of the RISC-V processor to be tested to the corresponding memory address space; 3. releasing the reset signal of the RISC-V processor to be tested on the programmable logic side. The second is to cooperate with the Mailbox hardware module to assist in the information interaction between the RISC-V processor and the hard-core processor side, including: 1. Based on the shared memory in the Mailbox hardware module, assist in accessing sensitive registers; 2. Based on the shared memory in the Mailbox hardware module, perform auxiliary calculations for computationally intensive tasks.

[0089] Taking RISC-V processor as an example, there are three privilege modes: M-MODE (machine mode) is the highest privilege mode that hardware threads in RISC-V can execute. Hardware threads running in M ​​mode have full access to memory, I / O and some low-level functions necessary for starting and configuring the system. Therefore, it is the only privilege mode that all standard RISC-V processors must implement. One of the most important tasks of this mode is to intercept and handle exceptions; S-MODE (supervisor mode) is an optional privilege mode designed to support modern Unix-like operating systems such as Linux, FreeBSD and Windows. S mode has higher privileges than U mode, but lower than M mode. The core function of this mode is to use page-based virtual memory; U-MODE (user mode usermode) application code can run in this mode. Therefore, the Linux kernel on the RISC-V processor runs in S-MODE, and the higher-level M-MODE runs OpenSBI. In addition to being a bootloader, OpenSBI also runs at the highest level of the processor as platform management firmware. S-MODE can call the functions provided by OpenSBI in M-MODE through ECALL instructions.

[0090] The virtual inter-core interrupt mechanism built based on Mailbox will play an important role in the bare metal test program or operating system boot process. Since the virtual interrupt mechanism used in the bare metal test program is similar to that used in the operating system boot process, the present invention will be explained using the operating system boot process as an example. When the RISC-V soft core to be tested is started, the initialization phase of the Linux kernel needs to fall into the supervisor binary interface (SBI) firmware code of M-MODE to execute an inter-core interrupt request. The Linux kernel on the RISC-V processor runs in S-MODE, and the higher-level M-MODE runs OpenSBI. OpenSBI is an open source implementation of SBI. In addition to being a boot program, it also runs as platform management firmware at the highest level of the processor. This article is compatible with the existing SoC-FPGA clock driver, and supports RISC-V to fall into the M-MODE firmware from the kernel state by adding corresponding interface functions to initiate a virtual inter-core interrupt to the PMU, such as Figure 3 shown.

[0091] Computing assistance. In the test platform, the ARM core is responsible for preparing the memory environment for the startup of the RISC-V core, that is, moving the RISC-V BOOT file from the SD card to the memory in advance, completing the bitstream configuration of the PL side, etc. And finally execute the service program during startup and operation to assist ECALL and other operations of RISC-V. In addition to the functional assistance required for RISC-V operation, the ARM core can also undertake some computing tasks. For example, in the research involving the RISC-V security framework, the ARM core is not only responsible for assisting RISC-V startup and forwarding IPI messages, it itself also has a higher main frequency and greater computing potential. Therefore, the SHA-3 calculation process on the RISC-V soft-core processor can be transferred to the ARM processor.

[0092] The startup and operation mode and address space planning of the test platform of the present invention. According to different test requirements, the platform and method of the present invention have three memory and peripheral usage modes, which are different in startup and operation mode:

[0093] Mode 1: Soft core exclusively occupies physical resources. In this mode, when the RISC-V processor under test needs complete interface resources on the SoC-FPGA, a memory and peripheral usage mode is proposed, which is mainly based on the processor under test on the programmable logic side and supplemented by the hard core processing system side (the processor under test obtains all peripheral interface resources, and the hard core processing system side only maintains the service program running);

[0094] Mode 2: Physical resource sharing between soft and hard cores based on static partitioning. In this mode, for the situation where the RISC-V processor to be tested does not need all the interface resources on the SoC-FPGA, but the hard core processing system side needs to perform more complex tasks, a mode of equal memory and peripheral usage between the processor to be tested on the programmable logic side and the hard core processing system side is proposed (each side occupies a set of physical peripheral resources, and the functions do not affect each other);

[0095] Mode 3: Physical resource sharing mode between soft and hard cores based on dynamic partitioning and virtualization. In this mode, if the RISC-V processor to be tested requires all interface resources on the SoC-FPGA and the hard core processing system needs to perform more complex tasks, a peer-to-peer memory and peripheral usage mode between the processor to be tested on the programmable logic side and the hard core processing system side is proposed if the SoC-FPGA device can support interface peripheral virtualization (both sides are isolated and share the same set of logic peripheral resources);

[0096] The following will use the widely used AMD (Xilinx) Zynq / ZynqMP series devices as a typical case to illustrate the above three memory and peripheral usage modes.

[0097] Mode 1: Soft core monopolizes physical resources. In order to enable the RISC-V processor to be tested to obtain sufficient interface peripheral resources on the SoC-FPGA, it is necessary to comprehensively consider the interactive operation sequence of the external communication interface and the memory access interface resources in the test platform. Considering that the platform described in the present invention has limited external communication interface and memory access interface resources from the perspective of basic devices, and at the same time requires the assistance of the PMU coprocessor and the ARM processor on the hard-core processing system side, if careful process planning is not performed, it is easy to cause conflicts between peripheral interaction and storage access. For early SoC-FPGA devices with relatively single peripheral resources, some peripheral interface resources cannot be shared because there is only one set and the hardware does not support virtualization. If the hard-core processor also starts the operating system, the two may occupy the memory and some peripheral resources on the board. Even for new SoC-FPGA devices with multiple sets of peripheral resources, considering that more than one set of peripheral resources is required in some special processor test scenarios (such as dual network card testing), all peripheral resources on the chip need to be provided to the processor to be tested. In these scenarios, the operating system should only be run on the processor to be tested.

[0098] In order to avoid such conflicts, the present invention proposes a special startup and operation procedure for such scenarios, and carefully plans the work intervention timing of the main processor of the hard-core processing system, so that the peripheral interaction operations of different processors are completely staggered in time sequence; at the same time, the main processor of the hard-core processing system and the RISC-V core to be tested are address-mapped, so that the shared memory space of different processors can be read and written in order to avoid conflicts. In this way, before the RISC-V core to be tested is officially started, the ARM processor has pre-installed the software required for the RISC-V core startup in the storage space, and has entered the service state after handing over the complete memory access and peripheral interface interaction permissions;

[0099] Based on the reuse and functional assistance of the external communication interface and memory access interface resources on the PS side mentioned above, the test platform adopts a unique startup and operation mode. Through time division multiplexing, the ARM and RISC-V in the test platform will alternately use the memory access and peripheral interfaces, and will not compete for the access rights to the peripherals in the same time period. In the final stage of startup, ARM transfers all access rights to the peripherals to the RISC-V core. The complete startup process will be completed by the hard-core processor and the processor to be tested.

[0100] Figure 4aThe complete startup process of the test platform is listed. First, the ARM processor starts, executes its own BootROM for initialization, and loads the ARM startup software from the SD card. Next, the ARM boot program is executed, and the PL configuration is completed in the process. After that, the ARM processor completes the loading of the RISC-V startup software and the release of the PL reset signal. At this point, the ARM processor completes the work in the test platform startup process and enters the service mode. After the reset is released, the RISC-V processor starts to execute, and the starting point of the execution is located in its own BootROM. Then it starts to execute the RISC-V boot program that has been loaded into the memory. The boot program here includes various boot methods. Taking the more classic OpenSBI+U-Boot boot as an example, the first part uses OpenSBI, which mainly performs RISC-V platform-related initialization. The second part is U-Boot, a boot program widely used in the embedded field, which can establish a command-line-based operating environment for loading the kernel. RISC-V can also be booted using BBL and other methods without restrictions. Then the kernel starts on the RISC-V processor and completes the startup process of the Linux distribution operating system.

[0101] It is worth noting that since the ARM side only uses the SDIO or network interface in the initial stage of power-on and boot, it will no longer occupy each interface on the PS side once the service program starts to execute. Therefore, the processor under test has full access to all interface resources on the PS side from the beginning of boot to the installation of the file system.

[0102] In the description of the peripheral resource access mode in the specific implementation case of the present invention, Figure 4b The figure above uses AMD (Xilinx) Zynq / ZynqMP series devices as an example. For other SoC-FPGA devices, their hard-core processors are not limited to the ARM instruction set and can be abstracted as Figure 4b shown.

[0103] Mode 2: Physical resource sharing between soft-core and hard-core based on static partitioning. In other scenarios, the processor to be tested only requires limited peripheral resource permissions. At the same time, the PS side needs to perform other tasks in addition to executing the service programs required for the RISC-V processor to start and run. In this type of scenario, the ARM processor will normally boot into the Linux stage, obtain the necessary peripheral access permissions, and run other application layer programs while executing the service program, which requires the use of certain peripheral resources. Some peripheral resources with large amounts of communication data, such as Ethernet GEM interface and SDIO interface, have DMA (Direct Memory Access) function. DMA technology itself exists to reduce the processing burden of the CPU, and its transmission process does not pass through the CPU. But in general, DMA needs to transmit directly to the real physical address. The peripheral resources of current SoC-FPGA devices often set up dedicated DMA modules for peripheral resources, most of which are single-channel DMA, such as Figure 6b shown.

[0104] Figure 5a The complete startup process of the test platform is listed. First, the ARM processor starts, executes its own BootROM for initialization, and loads the ARM startup software from the SD card. Next, the ARM boot program is executed and enters the Linux operating system normally. After entering the operating system, the service program is executed to complete the configuration of the PL, and then the ARM processor completes the loading of the RISC-V startup software and the release of the PL reset signal. At this point, the ARM processor has completed the preliminary work in the startup process of the test platform and entered the loop service mode. After the reset is released, the RISC-V processor starts to execute, and the starting point of the execution is located in its own BootROM, and then it starts to execute the RISC-V boot program that has been loaded into the memory. The boot program here includes various boot methods. Taking the more classic OpenSBI+U-Boot boot as an example, the first part uses OpenSBI, which mainly performs RISC-V platform-related initialization, and the second part is U-Boot, a boot program widely used in the embedded field, which can establish a command-line-based operating environment for loading the kernel. RISC-V can also choose to use BBL and other methods to boot, without restriction. Then the kernel starts on the RISC-V processor and completes the startup process of the Linux distribution operating system.

[0105] It is worth noting that Figure 5b As shown, since the ARM core and the RISC-V core to be tested use independent SDIO or network physical interfaces during the startup and operation stages, and the address spaces do not conflict with each other, the processor cores on both sides have full authority over their visible interface resources and do not affect each other.

[0106] In the description of the peripheral resource access mode in the specific implementation case of the present invention, Figure 5b The figure above uses AMD (Xilinx) Zynq / ZynqMP series devices as an example. For other SoC-FPGA devices, their hard-core processors are not limited to the ARM instruction set and can be abstracted as Figure 5b shown.

[0107] Mode 3: Physical resource sharing between soft-core and hard-core based on dynamic partitioning and virtualization methods. In addition to the single-channel DMA in the memory and peripheral usage mode 2, some peripherals may be equipped with multi-channel DMA. For these peripheral resources that support multi-channel DMA, if the cores on both sides of the SoC-FPGA need to be able to operate a device that supports DMA transmission at the same time, two cases need to be discussed. In the first case, the user pre-allocates a static address range before the platform is started, and there is a clear address mapping relationship for the RISC-V processor to be tested. In this case, it is similar to the memory and peripheral usage mode 2 and will not be repeated here. In the second case, the memory space is dynamically allocated, that is, after the ARM processor is started, memory resources are dynamically allocated to the RISC-V processor to be tested, and the physical starting address of this part of the memory space cannot be known in advance for the RISC-V processor. In this case, it is necessary to learn from the I / O peripheral virtualization technology and map the address of the DMA peripheral based on the IOMMU (Input / Output Memory Management Unit, a memory management unit for input and output devices) to finally achieve peripheral sharing. Different manufacturers have different names for this type of virtualization technology. Intel usually calls this hardware-assisted I / O virtualization technology VT-d (Virtualization Technology for directI / O). ARM has launched the corresponding SMMU (System MMU), which is equivalent to IOMMU at the conceptual level.

[0108] Figure 6aThe complete startup process of the test platform is listed. First, the ARM processor starts, executes its own BootROM for initialization, and loads the ARM startup software from the SD card. Next, the ARM boot program is executed and enters the Linux operating system normally. After entering the operating system, the memory is first dynamically allocated, and the SMMU is initialized and configured based on the memory allocation information. Then the service program is executed to complete the configuration of the PL. After that, the ARM processor completes the loading of the RISC-V startup software and the release of the PL reset signal. At this point, the ARM processor has completed its work in the test platform startup process and entered the loop service mode. After the reset is released, the RISC-V processor starts to execute, and the starting point of execution is located in its own BootROM, and then starts to execute the RISC-V boot program that has been loaded into the memory. The boot program here includes various startup boot methods. Taking the more classic OpenSBI+U-Boot boot as an example, the first part uses OpenSBI, which mainly performs RISC-V platform-related initialization, and the second part is U-Boot, a boot program widely used in the embedded field, which can establish a command-line-based operating environment for loading the kernel. RISC-V can also choose to use BBL and other methods to boot, without restriction. The kernel then starts on the RISC-V processor and completes the boot process of the Linux distribution operating system.

[0109] It is worth noting that Figure 6b As shown in the figure, although the ARM core and the RISC-V core to be tested use the same SDIO or network physical interface during the startup and operation phases, they communicate based on different DMA channels. For the RISC-V side, address mapping is performed with the assistance of IOMMU (called SMMU in the ARM architecture in this example, which is conceptually equivalent). And the address spaces do not conflict with each other, and the processor cores on both sides have full authority over the interface resources visible to themselves, without affecting each other.

[0110] In the description of the peripheral resource access mode in the specific implementation case of the present invention, Figure 6b The AMD (Xilinx) Zynq / ZynqMP series devices are used as an example. For other SoC-FPGA devices, their hard-core processors are not limited to the ARM instruction set, and the memory management unit of the input and output devices is not limited to SMMU. It can be any other device that implements the IOMMU function. In general, it can be abstracted as Figure 6b shown.

[0111] like Figure 7As shown, Mailbox is designed and implemented based on the on-chip memory unit and its read-write control logic unit in the SoC-FPGA chip. The storage space is very small and can only transmit key parameters but is not suitable for transmitting large blocks of data. When the processor under test is running, the processor under test communicates with the platform management unit PMU in the SoC-FPGA through the Mailbox module, which specifically includes: the processor under test starts to initiate inter-core interrupts; the processor under test runs in M-MODE; the inter-core interrupt parameters are written to the parameter segment of the Mailbox module through the peripheral interface and the inter-core interrupt type is indicated, and the request mark segment of the Mailbox module is marked; the hard-core processor processes the inter-core interrupt request according to the request mark segment and the parameter segment, accesses the sensitive register through the PMU, and sends the information result returned by the PMU to the Mailbox module; the processor under test reads back the information result from the Mailbox module and clears the mark in the request mark segment.

[0112] like Figure 8 As shown, complex computing tasks mainly refer to some tasks with high computing complexity. For the processor to be tested at a lower clock frequency, it takes a long time to get the result. Typical examples include encryption and decryption, hash calculation, etc. Such computing tasks sometimes cause the processor to be tested to time out and get stuck. In step 5, when the processor to be tested performs the computing task, the communication with the hard-core processor through the Mailbox module specifically includes: the processor to be tested starts to perform the computing task, executes ECALL (environment call, Environment CALL) to fall into M-MODE, writes the address of the data to be calculated to the parameter segment of the Mailbox module through the peripheral interface and indicates the required auxiliary computing type, and marks the request marking segment of the Mailbox module; the hard-core processor reads the data to be calculated according to the request marking segment and the parameter segment to perform the computing task, obtains the computing result and writes it into the shared memory in the SoC-FPGA; the processor to be tested reads back the computing result from the shared memory and clears the mark in the request marking segment.

[0113] For example, S mode does not directly control clock interrupts and software interrupts, but uses the ECALL instruction to request M mode to set a timer or send an inter-processor interrupt on its behalf. The specific implementation of ECALL is mainly based on SBI, the Supervisor Binary Interface.

[0114] The following is a system embodiment corresponding to the above method embodiment. This embodiment can be implemented in conjunction with the above embodiment. The relevant technical details mentioned in the above embodiment are still valid in this embodiment. In order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the above embodiment.

[0115] The present invention also proposes a test system for processor system-level design, which is characterized by comprising:

[0116] Module 1 is used to obtain the hardware source code and software source code of the processor design to be tested, and select the memory and peripheral usage mode required for the test according to user requirements and device conditions;

[0117] Module 2, for a processor test platform based on SoC-FPGA, detects the processor to be tested and performs interface standardization processing on it according to the hardware source code, and divides all interfaces of the processor to be tested by function; the processor test platform deploys the processor to be tested in the form of a soft core to the programmable logic side of the SoC-FPGA in combination with the memory and peripheral usage mode, and maps the address space of the processor to be tested to the address space of the SoC-FPGA hard-core processor through a customized logic circuit, so as to realize exclusive or shared use of the hard-core processor memory and peripheral resources;

[0118] Module 3 is used to build a complete FPGA project and finally generate a hardware configuration file; compile the software source code and generate a software load for testing;

[0119] Module 4 is used to enable the hard-core processor in the SoC-FPGA to assist in starting the processor to be tested according to the selected memory and peripheral usage mode;

[0120] Module 5 is used to obtain and execute the software load after the processor to be tested is started and runs. The entire process of starting and executing the processor to be tested exclusively or sharedly uses the memory and peripheral interface resources of the SoC-FPGA according to the memory and peripheral usage mode.

[0121] The test system for processor system-level design is characterized in that:

[0122] When the processor under test needs to read and write sensitive registers of the peripheral interface, the processor under test selects to pass the read and write tasks to the platform management unit of the SoC-FPGA through the hardware Mailbox module during operation, which includes:

[0123] The processor to be tested initiates an inter-core interrupt: the processor to be tested is put into the highest privilege mode; the inter-core interrupt parameters are written to the parameter segment of the hardware Mailbox module through the peripheral interface and the inter-core interrupt type is indicated, and the request mark segment of the Mailbox module is marked;

[0124] Transferring the read and write tasks of sensitive registers: the hard-core processor processes the inter-core interrupt request according to the request tag segment and the parameter segment, accesses the sensitive registers through the platform management unit, and sends the information result returned by the platform management unit to the Mailbox module; returning the access result: the processor under test reads back the information result from the Mailbox module and clears the mark in the request tag segment;

[0125] When there is a test load that needs to perform complex calculations during the startup or operation of the processor to be tested, the processor to be tested chooses to communicate with the hard-core processor through the Mailbox module when performing the calculation task, specifically including:

[0126] In the process of executing the computing task, the processor to be tested is put into the highest privilege mode, and the shared memory address where the data to be calculated is located is written to the parameter segment of the Mailbox module through the peripheral interface, and the required auxiliary computing type is indicated, and the request marking segment of the Mailbox module is marked;

[0127] The hard-core processor reads the data to be calculated from the shared memory according to the request marker segment and the parameter segment, performs the calculation task, and writes the calculation result into the shared memory;

[0128] The processor to be tested reads back the calculation result from the shared memory and clears the mark in the request mark segment;

[0129] The memory and peripheral usage mode is a soft-core exclusive physical resource mode. In the soft-core exclusive physical resource mode, the processor to be tested obtains all peripheral interface resources of the SoC-FPGA, and the hard-core processor only maintains the operation of the service program, which is a program used to assist in starting the processor to be tested.

[0130] Or the memory and peripheral usage mode is a physical resource sharing mode between soft and hard cores based on static partitioning. In this physical resource sharing mode between soft and hard cores based on static partitioning, the processor to be tested obtains a part of the peripheral interface resources of the SoC-FPGA. In addition to maintaining the operation of the service program, the hard-core processor also performs other tasks through another part of the peripheral interface resources of the SoC-FPGA.

[0131] Or the memory and peripheral usage mode is a physical resource sharing mode between soft-core and hard-core based on dynamic partitioning and virtualization. In this physical resource sharing mode between soft-core and hard-core based on dynamic partitioning and virtualization, the interface peripherals of the SoC-FPGA are virtualized and shared with the hard-core processor and the processor to be tested. The processor to be tested obtains all interface resources on the SoC-FPGA, and the hard-core processor, in addition to maintaining the operation of the service program, also performs other tasks by sharing peripheral interface resources.

[0132] The present invention also proposes a storage medium for storing a program for executing any one of the test methods for processor system-level design.

[0133] The present invention also provides a client, which is used for the test system oriented to processor system level design.

Claims

1. A test method for processor system-level design, characterized in that: include: Step 1: Obtain the hardware source code and software source code of the processor to be tested, and select the memory and peripheral usage mode required for the test according to user requirements and device conditions; Step 2: The processor test platform based on SoC-FPGA detects the processor to be tested and performs interface standardization processing on it according to the hardware source code, and divides all interfaces of the processor to be tested according to function; the processor test platform combines the memory and peripheral usage mode, deploys the processor to be tested in the form of a soft core to the programmable logic side of the SoC-FPGA, and maps the address space of the processor to be tested to the address space of the SoC-FPGA hard-core processor through a customized logic circuit, so as to realize exclusive or shared use of the hard-core processor memory and peripheral resources; Step 3: Build a complete FPGA project and finally generate a hardware configuration file; Compile the software source code and generate software load for testing; Step 4: The hard-core processor in the SoC-FPGA assists the startup of the processor to be tested according to the selected memory and peripheral usage mode; Step 5: After the processor to be tested is started and runs, the software load is obtained and executed; the entire process of starting and executing the processor to be tested exclusively or sharedly uses the memory and peripheral interface resources of the SoC-FPGA according to the memory and peripheral usage mode; The memory and peripheral usage mode is a soft-core exclusive physical resource mode. In the soft-core exclusive physical resource mode, the processor to be tested obtains all peripheral interface resources of the SoC-FPGA, and the hard-core processor only maintains the operation of the service program, which is a program for assisting in starting the processor to be tested; or The memory and peripheral usage mode is a physical resource sharing mode between soft-core and hard-core based on static partitioning. Under the physical resource sharing mode between soft-core and hard-core based on static partitioning, the processor to be tested obtains a part of the peripheral interface resources of the SoC-FPGA, and the hard-core processor, in addition to maintaining the operation of the service program, also performs other tasks through another part of the peripheral interface resources of the SoC-FPGA; or The memory and peripheral usage mode is a physical resource sharing mode between soft and hard cores based on dynamic partitioning and virtualization. Under this physical resource sharing mode between soft and hard cores based on dynamic partitioning and virtualization, the interface peripherals of the SoC-FPGA are virtualized and shared with the hard-core processor and the processor to be tested. The processor to be tested obtains all interface resources on the SoC-FPGA. In addition to maintaining the operation of the service program, the hard-core processor also performs other tasks by sharing peripheral interface resources.

2. The test method for processor system-level design according to claim 1, characterized in that: When the processor under test needs to read and write sensitive registers of the peripheral interface, the processor under test selects to pass the read and write tasks to the platform management unit of the SoC-FPGA through the hardware Mailbox module during operation, which includes: The processor to be tested initiates an inter-core interrupt: the processor to be tested is put into the highest privilege mode; the inter-core interrupt parameters are written to the parameter segment of the hardware Mailbox module through the peripheral interface and the inter-core interrupt type is indicated, and the request mark segment of the Mailbox module is marked; Transferring the reading and writing tasks of sensitive registers: the hard core processor processes the inter-core interrupt request according to the request tag segment and the parameter segment, accesses the sensitive registers through the platform management unit, and sends the information results returned by the platform management unit to the Mailbox module; The processor to be tested obtains the access result: the processor to be tested reads back the information result from the Mailbox module and clears the mark in the request mark segment.

3. The test method for processor system-level design as claimed in claim 1, characterized in that: When there is a test load that needs to perform complex calculations during the startup or operation of the processor to be tested, the processor to be tested chooses to communicate with the hard-core processor through the Mailbox module when performing the calculation task, specifically including: In the process of executing the computing task, the processor to be tested is put into the highest privilege mode, and the shared memory address where the data to be calculated is located is written to the parameter segment of the Mailbox module through the peripheral interface, and the required auxiliary computing type is indicated, and the request marking segment of the Mailbox module is marked; The hard-core processor reads the data to be calculated from the shared memory according to the request marker segment and the parameter segment, performs the calculation task, and writes the calculation result into the shared memory; The processor to be tested reads back the calculation result from the shared memory and clears the mark in the request mark segment.

4. A test system for processor system-level design, characterized in that: include: Module 1 is used to obtain the hardware source code and software source code of the processor design to be tested, and select the memory and peripheral usage mode required for the test according to user requirements and device conditions; Module 2, for a processor test platform based on SoC-FPGA, detects the processor to be tested and performs interface standardization processing on it according to the hardware source code, and divides all interfaces of the processor to be tested by function; the processor test platform deploys the processor to be tested in the form of a soft core to the programmable logic side of the SoC-FPGA in combination with the memory and peripheral usage mode, and maps the address space of the processor to be tested to the address space of the SoC-FPGA hard-core processor through a customized logic circuit, so as to realize exclusive or shared use of the hard-core processor memory and peripheral resources; Module 3 is used to build a complete FPGA project and finally generate a hardware configuration file; Compile the software source code and generate software load for testing; Module 4 is used to enable the hard-core processor in the SoC-FPGA to assist in starting the processor to be tested according to the selected memory and peripheral usage mode; Module 5 is used to obtain and execute the software load after the processor to be tested starts running; the entire process of starting and executing the processor to be tested exclusively or sharedly uses the memory and peripheral interface resources of the SoC-FPGA according to the memory and peripheral usage mode; The memory and peripheral usage mode is a soft-core exclusive physical resource mode. In the soft-core exclusive physical resource mode, the processor to be tested obtains all peripheral interface resources of the SoC-FPGA, and the hard-core processor only maintains the operation of the service program, which is a program for assisting in starting the processor to be tested; or The memory and peripheral usage mode is a physical resource sharing mode between soft-core and hard-core based on static partitioning. Under the physical resource sharing mode between soft-core and hard-core based on static partitioning, the processor to be tested obtains a part of the peripheral interface resources of the SoC-FPGA, and the hard-core processor, in addition to maintaining the operation of the service program, also performs other tasks through another part of the peripheral interface resources of the SoC-FPGA; or The memory and peripheral usage mode is a physical resource sharing mode between soft and hard cores based on dynamic partitioning and virtualization. Under this physical resource sharing mode between soft and hard cores based on dynamic partitioning and virtualization, the interface peripherals of the SoC-FPGA are virtualized and shared with the hard-core processor and the processor to be tested. The processor to be tested obtains all interface resources on the SoC-FPGA. In addition to maintaining the operation of the service program, the hard-core processor also performs other tasks by sharing peripheral interface resources.

5. The test system for processor system-level design as claimed in claim 4, characterized in that: When the processor under test needs to read and write sensitive registers of the peripheral interface, the processor under test selects to pass the read and write tasks to the platform management unit of the SoC-FPGA through the hardware Mailbox module during operation, which includes: The processor to be tested initiates an inter-core interrupt: the processor to be tested is put into the highest privilege mode; the inter-core interrupt parameters are written to the parameter segment of the hardware Mailbox module through the peripheral interface and the inter-core interrupt type is indicated, and the request mark segment of the Mailbox module is marked; Transferring the reading and writing tasks of sensitive registers: the hard core processor processes the inter-core interrupt request according to the request tag segment and the parameter segment, accesses the sensitive registers through the platform management unit, and sends the information results returned by the platform management unit to the Mailbox module; The processor to be tested obtains the access result: the processor to be tested reads back the information result from the Mailbox module and clears the mark in the request mark segment; When there is a test load that needs to perform complex calculations during the startup or operation of the processor to be tested, the processor to be tested chooses to communicate with the hard-core processor through the Mailbox module when performing the calculation task, specifically including: In the process of executing the computing task, the processor to be tested is put into the highest privilege mode, and the shared memory address where the data to be calculated is located is written to the parameter segment of the Mailbox module through the peripheral interface, and the required auxiliary computing type is indicated, and the request marking segment of the Mailbox module is marked; The hard-core processor reads the data to be calculated from the shared memory according to the request marker segment and the parameter segment, performs the calculation task, and writes the calculation result into the shared memory; The processor to be tested reads back the calculation result from the shared memory and clears the mark in the request mark segment.

6. A storage medium for storing a program for executing the test method for processor system-level design according to any one of claims 1 to 3.

7. A client, used in the test system for processor system-level design as claimed in any one of claims 4 or 5.

Images