Intelligent terminal SoC prototype verification method and system based on FPGA partial dynamic reconstruction

Abstract

The embodiment of the invention provides an intelligent terminal SoC prototype verification method and system based on FPGA partial dynamic reconstruction. The method comprises the steps of obtaining a predetermined dynamic module and a predetermined static module; wherein the dynamic module and the static module are obtained by adaptively dividing hardware resources of a mobile intelligent terminal chip; performing prototype joint verification based on the dynamic module and the static module to generate a coverage rate report; if the coverage rate report represents that an error exists, a dynamic module hot update mode is selected; determining an error type in a dynamic module hot update mode; according to the error type, error repair is carried out, and a repaired file is obtained; and performing joint simulation and system operation verification based on the repaired file to obtain a verification result of the SoC prototype of the mobile intelligent terminal. According to the scheme, the verification efficiency of the SoC prototype of the intelligent terminal can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of high-end chips of mobile intelligent terminals, in particular to an intelligent terminal SoC prototype verification method and system based on FPGA partial dynamic reconfiguration. BACKGROUND

[0002] With the exponential growth of SoC complexity, the RTL design, synthesis, layout, bitstream generation and download processes consume a lot of time. For example, the complete FPGA synthesis and bitstream generation of a certain key functional module of a 28nm process mobile chip may take several hours (4-6 hours on average per time). This results in a long overall verification period, slow iteration, and an increased risk of repairing errors before tape-out. The "hot update" in traditional FPGA prototype verification usually refers to logic reloading of functional modules, but for non-logic parameter modification (such as configuration registers) or small logic changes, a full bitstream still needs to be generated, which is time-consuming and disruptive. Existing hot update methods, such as SRAM-based parameter update, usually do not support high-speed, real-time update, or the update process is cumbersome and difficult to meet the real-time parameter adjustment requirements in high-speed interface or low-power scenarios. With the application of advanced packaging technologies such as Chiplet and 3D stacking, the interfaces between chips and their collaborative work need to be verified. The existing FPGA verification scheme is often limited by interface standards and resource allocation when adapting to heterogeneous multi-chip collaborative verification, making it difficult to efficiently support complex packaging structures. Mobile terminals are extremely sensitive to power consumption and performance. However, traditional verification methods lack the ability to monitor and dynamically adjust power consumption and performance in real time during runtime, making it difficult to quickly identify and optimize power or performance bottlenecks in the prototype stage. SUMMARY

[0003] The embodiments of the present application aim to provide an intelligent terminal SoC prototype verification method and system based on FPGA partial dynamic reconfiguration, which can improve the verification efficiency of intelligent terminal SoC prototypes.

[0004] The technical solution of the present application is implemented as follows: In a first aspect, the embodiments of the present application provide an intelligent terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration, which comprises: acquiring a predetermined dynamic module and a static module; wherein the dynamic module and the static module are obtained by adaptively dividing the hardware resources of a mobile intelligent terminal chip; based on the dynamic module and the static module, performing prototype joint verification to generate a coverage report; if the coverage report indicates that there is an error, selecting a dynamic module hot update mode; In the dynamic module hot update mode, determine the error type; and according to the error type, perform error repair to obtain a repaired file; Based on the repaired file, joint simulation and system operation verification are performed to obtain a verification result of the mobile intelligent terminal SoC prototype.

[0005] In the above scheme, before the pre-determined dynamic module and static module are obtained, the method further comprises: Obtaining a plurality of functional modules of a register transfer level of the mobile intelligent terminal SoC to be verified; Calculating the coupling degree corresponding to each of the plurality of functional modules; For the coupling degree of each functional module in the plurality of functional modules, if the coupling degree of each functional module is greater than a preset coupling degree, each functional module is determined as the static module; If the coupling degree of each functional module is less than or equal to the preset coupling degree, each functional module is determined as the dynamic module.

[0006] In the above scheme, the calculation of the coupling degree corresponding to each of the plurality of functional modules comprises: For each functional module in the plurality of functional modules, the number of signal interactions between each functional module and other functional modules is determined; The total number of modules of the plurality of functional modules is determined; Based on the number of signal interactions between each functional module and other functional modules and the total number of modules of the plurality of functional modules, the coupling degree of each functional module is calculated to obtain the coupling degree corresponding to each of the plurality of functional modules.

[0007] In the above scheme, the static module is fixed in the bit stream of the FPGA, and contains the fixed logic of the clock network, high-speed interface or hardware accelerator of the mobile intelligent terminal SoC; the static module is merged into a single bit stream, and only needs full compilation when it is first synthesized; The dynamic module supports runtime update, and contains the state machine jump logic of the processor core, the algorithm parameter of the AI accelerator or the register configuration table of the GPU.

[0008] In the above scheme, in the dynamic module hot update mode, the error type is determined, and according to the error type, error repair is performed to obtain a repaired file, comprising: In the dynamic module hot update mode, the error type is determined; wherein the error type includes a logic error and / or a data parameter error; Based on the logic error and / or the data parameter error, the error repair mode corresponding to the error type is determined; According to the error repair mode corresponding to the error type, the error type is repaired to obtain the repaired file.

[0009] In the above solution, the determining of the error repair mode corresponding to the error type based on the logic error and / or the data parameter error comprises: If the error type is the logic error, it is determined that the error repair mode corresponding to the logic error is a partial dynamic reconfiguration mode. If the error type is the data parameter error, it is determined that the error repair mode corresponding to the data parameter error is an SRAM hot patch mode. If the error type is the logic error and the data parameter error, it is determined that the error repair mode corresponding to the logic error and the data parameter error is the partial dynamic reconfiguration mode and the SRAM hot patch mode.

[0010] In the above solution, the method further comprises: If the error type is a logic error, an incremental compilation and a differential bitstream loading processing logic error of a mobile EDA tool are automatically triggered. If the error type is a data parameter error, a script is called to regenerate configuration data to repair the data parameter error. In a case where the repair of the logic error or the repair of the data parameter error is completed, a critical function regression test is automatically performed.

[0011] In a second aspect, an embodiment of the present application provides a smart terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration, which comprises an acquisition module, a generation module, a selection module, a determination module and a verification module, wherein: The acquisition module is configured to acquire a pre-determined dynamic module and a static module, wherein the dynamic module and the static module are obtained by self-adaptively dividing hardware resources of a mobile smart terminal chip. The generation module is configured to perform prototype joint verification based on the dynamic module and the static module, and generate a coverage report. The selection module is configured to select a dynamic module hot update mode if the coverage report indicates that there is an error. The determination module is configured to determine an error type in the dynamic module hot update mode, and perform error repair according to the error type to obtain a repaired file. The verification module is configured to perform joint simulation and system running verification based on the repaired file, and obtain a verification result of a mobile smart terminal SoC prototype.

[0012] In a third aspect, an embodiment of the present application provides a smart terminal SoC prototype verification device based on FPGA partial dynamic reconfiguration, which comprises a processor and a memory, wherein: the memory, configured to store a computer program; the processor, configured to call and run the computer program from the memory, so as to execute the method according to the first aspect.

[0013] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores executable instructions for causing a processor to execute the method according to the first aspect.

[0014] The embodiment of the present application provides an intelligent terminal SoC prototype verification method and system based on FPGA partial dynamic reconfiguration, which comprises the following steps: acquiring a predetermined dynamic module and a static module; wherein the dynamic module and the static module are obtained by adaptively dividing hardware resources of a mobile intelligent terminal chip; performing prototype joint verification based on the dynamic module and the static module, to generate a coverage report; if the coverage report indicates that there is an error, selecting a dynamic module hot update mode; determining an error type in the dynamic module hot update mode; and performing error repair according to the error type, to obtain a repaired file; performing joint simulation and system running verification based on the repaired file, to obtain a verification result of the mobile intelligent terminal SoC prototype. In the above scheme, the dynamic module and the static module are obtained by adaptively dividing the hardware resources of the mobile intelligent terminal chip; the dynamic module is subjected to prototype joint verification, and if the coverage report indicates that there is an error, the dynamic module hot update mode is selected; in the dynamic module hot update mode, error repair is performed according to the error type, and the repaired file is subjected to joint simulation and system running verification, to obtain the verification result of the mobile intelligent terminal SoC prototype. Since the dynamic module and the static module are divided, after an error occurs in the dynamic module, only the dynamic module with the error is updated, so that the update time is shortened, and the waiting time of the verification process is significantly reduced; at the same time, the verification time of the dynamic module which needs to be frequently iterated is shortened from several hours to several minutes or even seconds, and the verification efficiency is greatly improved. BRIEF DESCRIPTION OF DRAWINGS

[0015] The drawings in the present application are incorporated into the description and form a part of the description, which show the embodiments consistent with the present application, and are used to explain the technical scheme of the present application together with the description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0016] The flowchart shown in the drawing is only an exemplary illustration, not necessarily including all contents and operations / steps, and not necessarily executed in the order as described. For example, some operations / steps can be further decomposed, and some operations / steps can be combined or partially combined, so that the actual execution order can be changed according to actual conditions.

[0017] Figure 1 An optional flowchart of a smart terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration provided by the embodiment of the present application; Figure 2 A system architecture diagram of a high-end chip prototype verification platform of a mobile smart terminal based on FPGA provided by the embodiment of the present application; Figure 3 A dynamic and static module division rule diagram based on timing critical path analysis and functional coupling quantification evaluation provided by the embodiment of the present application; Figure 4 A general flowchart of a prototype verification platform provided by the embodiment of the present application; Figure 5 A specific working step diagram of a software part of a prototype verification platform provided by the embodiment of the present application; Figure 6 A specific working step diagram of a hardware part of a prototype verification platform provided by the embodiment of the present application; Figure 7 A structure diagram of a smart terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration provided by the embodiment of the present application; Figure 8 A structure diagram of a smart terminal SoC prototype verification device based on FPGA partial dynamic reconfiguration provided by the embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical scheme and advantages of the embodiment of the present application more clear, the specific technical scheme of the present application will be further described in combination with the drawings in the embodiment of the present application. The following embodiments are used to illustrate the present application, but not to limit the scope of the present application.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0020] In the following description, reference is made to "some embodiments", "the present embodiment", "embodiments of the present application", and the like, which describe a subset of all possible embodiments, but it is to be understood that "some embodiments" can be the same or different from one another, and that "some embodiments" can be combined with one another, without conflicts.

[0021] If the application file appears similar description of "first / second", the following description is added, in the following description, the term "first\second\third" is only to distinguish similar objects, and does not represent the specific order of the object, and it can be understood that "first\second\third" can be interchanged with the specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0022] The embodiments of the present application provide a smart terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration, Figure 1 An optional flowchart of a smart terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration provided by the embodiments of the present application will be described in combination with Figure 1 The steps shown will be described.

[0023] S101, obtaining a predetermined dynamic module and a static module; wherein the dynamic module and the static module are obtained by self-adaptively dividing the hardware resources of the mobile smart terminal chip.

[0024] In some embodiments of the present application, the dynamic module and the static module are obtained by self-adaptively dividing the hardware resources of the mobile smart terminal chip in advance; the static module is fixed in the bit stream of the FPGA, and contains the fixed logic of the clock network, high-speed interface or hardware accelerator of the mobile smart terminal SoC; the dynamic module supports runtime update, and contains the state machine jump logic of the processor core, the algorithm parameter of the AI accelerator or the register configuration table of the GPU.

[0025] In some embodiments of the present application, the smart terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration can be used in the scene of mobile smart terminal SoC prototype verification.

[0026] In some embodiments of the present application, the smart terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration is suitable for a smart terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration.

[0027] In some embodiments of the present application, the dynamic module and the static module are obtained.

[0028] S102, based on the dynamic module and the static module, prototype joint verification is performed to generate a coverage report; if the coverage report indicates that there is an error, a dynamic module hot update mode is selected.

[0029] In some embodiments of the present application, in the Verdi environment, the simulation is started by associating the MIF file, based on the dynamic module and the static module, prototype joint verification is performed to generate a coverage report coverage.html. If the verification is passed, the next step of dynamic verification is entered; if the coverage report indicates that there is an error, a dynamic module hot update mode is selected.

[0030] S103, in the dynamic module hot update mode, the error type is determined; and according to the error type, error repair is performed to obtain a repaired file.

[0031] In some embodiments of the present application, in the dynamic module hot update mode, the error type is determined; wherein the error type includes a logic error and / or a data parameter error; based on the logic error and / or the data parameter error, an error repair method corresponding to the error type is determined; according to the error repair method corresponding to the error type, the error type is repaired to obtain a repaired file.

[0032] In some embodiments of the present application, after the RTL is divided into a dynamic module and a static module, a dynamic module hot update mode is selected to determine whether it is a logic error or a data parameter error. For example, RTL design defects (such as state machine jump errors and combination logic calculation errors) are logic errors, and configuration parameters, weight data or initialization value errors in a memory (SRAM / register) are data parameter errors.

[0033] In some embodiments of the present application, for a logic error problem, such as an algorithm circuit design error of an AI accelerator leading to functional abnormalities, the system automatically calls the Vivado tool to perform incremental compilation on the problematic module to generate a small-difference bitstream file containing only the modified part, and then completes partial dynamic reconstruction of the FPGA chip through a JTAG or USB interface to realize logic hot update.

[0034] In some embodiments of the present application, if it is a data parameter problem, such as an image processor calibration parameter setting error, the system generates a corrected Hex file through the Keil development environment, converts it into a COE format, and then directly writes it into a specified address region of the FPGA internal SRAM through the DMA channel of the ICP debugging interface to complete hot patch update.

[0035] Exemplarily, the system distinguishes logical errors from data parameter errors through an automatic mechanism, and realizes dual-mode hot updating suitable for high-end chips of mobile intelligent terminals. For logical errors, a partial dynamic reconfiguration (PR) mode of FPGA is adopted, a physical constraint file (XDC) and an IP integrator (IPIntegrator) of an EDA tool (such as a lightweight version of Vivado) suitable for mobile terminals are used to accurately locate and modify a module, a design checkpoint (DCP) technology is used to generate a differential bitstream (typically <1MB in size) containing logical differences, and the differential bitstream is loaded into a specified reconfiguration area of the FPGA within 1 second through a USB or wireless debugging interface of the mobile device, so as to ensure that a user has no perception when using a key application (such as taking a photo or making a video call).

[0036] For data parameter errors, an SRAM hot patch mode is adopted, a Hex file is generated through Keil compilation, is converted into a COE format through a Perl script, and is bound to an IP core of an EDA tool of the mobile terminal to generate an MIF file, the MIF file is written into an SRAM address mapping area at a speed of 100 MB / s through a DMA channel of a debugging interface, and a memory protection unit (MPU) technology is used to ensure update safety. S104, based on the repaired file, joint simulation and system running verification are performed to obtain a verification result of the mobile intelligent terminal SoC prototype.

[0037] In some embodiments of the present application, based on the repaired file, joint simulation and system running verification are performed on the dynamic module to obtain a verification result of the mobile intelligent terminal SoC prototype.

[0038] It can be understood that the hardware resources of the mobile intelligent terminal chip are adaptively divided to obtain the dynamic module and the static module; the dynamic module is subjected to prototype joint verification, and if it is found from a coverage report that there is an error, a dynamic module hot updating mode is selected; in the dynamic module hot updating mode, error repair is performed according to the error type, joint simulation and system running verification are performed on the repaired file, and a verification result of the mobile intelligent terminal SoC prototype is obtained. Since the dynamic module and the static module are divided, only the dynamic module with an error is updated after the error occurs in the dynamic module, so that the updating time is shortened, and the waiting time of the verification process is significantly reduced; at the same time, the verification time of the dynamic module which needs to be frequently iterated is shortened from several hours to several minutes or even seconds, and the verification efficiency is greatly improved.

[0039] In some embodiments of the present application, before S101 is performed, S105-S108 are further performed, as follows: S105, a plurality of functional modules of a register transfer level of the mobile intelligent terminal SoC to be verified are obtained.

[0040] S106, calculate the coupling degrees of the plurality of function modules respectively.

[0041] In some embodiments of the present application, for each function module in the plurality of function modules, the number of signal interactions of each function module with other function modules is determined; the total number of modules of the plurality of function modules is determined; and the coupling degree of each function module is calculated based on the number of signal interactions of each function module with other function modules and the total number of modules of the plurality of function modules, to obtain the coupling degrees of the plurality of function modules respectively.

[0042] S107, for the coupling degree of each function module in the plurality of function modules, if the coupling degree of each function module is greater than a preset coupling degree, each function module is determined as a static module.

[0043] In some embodiments of the present application, for the coupling degree of each function module in the plurality of function modules, if the coupling degree of each function module is greater than a preset coupling degree, each function module is determined as a static module.

[0044] It should be noted that the coupling degree of each function module in the plurality of function modules is the coupling degree of each function module in the plurality of function modules. The coupling degrees of each function module are compared with the preset coupling degree respectively, and it is determined whether each function module is a static module or a dynamic module. For example, for any one module in the plurality of function modules, if the coupling degree of any one module is greater than a preset coupling degree, any one module is determined as a static module.

[0045] S108, if the coupling degree of each function module is less than or equal to a preset coupling degree, each function module is determined as a dynamic module.

[0046] In some embodiments of the present application, for the coupling degree of each function module in the plurality of function modules, if the coupling degree of each function module is less than or equal to a preset coupling degree, each function module is determined as a dynamic module.

[0047] It should be noted that the coupling degree of each function module in the plurality of function modules is the coupling degree of each function module in the plurality of function modules. The coupling degrees of each function module are compared with the preset coupling degree respectively, and it is determined whether each function module is a static module or a dynamic module. For example, for any one module in the plurality of function modules, if the coupling degree of any one module is less than or equal to a preset coupling degree, any one module is determined as a dynamic module.

[0048] For example, in view of the strict requirements of high-end chips of mobile intelligent terminals for low power consumption and high integration, an intelligent module division strategy based on task execution timing analysis and functional correlation quantitative evaluation is adopted, combined with the custom design of a special integrated circuit (SoC) and the dynamic reconfiguration technology of a field programmable gate array (FPGA) in the technical branch of mobile terminal chips. Through a standardized coupling degree calculation model (Ninter is the number of inter-module interaction signals, and Ntotal is the total number of module signals), 30% is taken as the threshold to distinguish static modules from dynamic modules. The RTL design of the mobile intelligent terminal SoC to be verified is divided into static modules and dynamic modules, and the division is stopped when the size of the dynamic module is less than 5% of the total design or the coupling degree is ≤10%, wherein: The static module is solidified in the bit stream of the FPGA, including the clock network of the mobile intelligent terminal SoC, high-speed interfaces (such as MIPI, DDR controller) or fixed logic of hardware accelerators; the dynamic module supports runtime update, including the state machine jump logic of the processor core, the algorithm parameters of the AI accelerator or the register configuration table of the GPU; the static module is merged into a single bit stream, and only full compilation is required at the first synthesis.

[0049] It should be noted that the division threshold, i.e., the preset coupling degree, is 30%.

[0050] Modular design based on FPGA dynamic reconfigurable architecture: Referring to the dynamic modeling idea of advanced process technology in the classification system "mobile intelligent terminal chip technology", through the intelligent module division strategy (based on timing critical path analysis and functional coupling degree quantitative evaluation), the adaptive division of hardware resources is realized. For example, high-coupling-degree modules (>30%) such as power management and high-speed interfaces are solidified as static modules to ensure system stability; while low-coupling-degree modules (30%) such as AI algorithms and image processing are divided into dynamic modules, and the logic and data are updated independently through the partial reconfiguration technology of FPGA. 15% of the timing margin is reserved for clock domain crossing (CDC) processing to ensure the safety of dynamic update.

[0051] In the static module solidification mechanism, for high-coupling-degree modules (coupling degree > 30%) such as power management and baseband communication of mobile terminal cores, a bit stream solidification strategy is adopted. For example, the typical coupling degree of the power management module is more than 80%, and there are a large number of signal interactions with other modules in the system, and dynamic update is easy to cause voltage fluctuation and communication interruption. Through solidification processing, the stability of basic functions such as stable power output and reliable transmission of baseband signals is ensured, the fixed layout and wiring design guarantees the timing margin, and the additional power consumption caused by frequent update is reduced. The dynamic module flexible updating mechanism is used for low-coupling modules (coupling degree ≤ 30 %) such as image recognition algorithms and audio processing. The partial reconfiguration technology of the FPGA and the SRAM memory mapping mechanism are used to realize independent updating of logic and data. Taking the AI portrait beautification algorithm module of a mobile terminal as an example, the coupling degree is about 20 %. Only the image data interface is used to receive input and output processing results. The updating does not affect the camera sensor or the memory controller. The iteration efficiency of the frequently optimized parts such as AI algorithms and communication protocol parameters in mobile devices is effectively improved. At the same time, the FPGA resources are saved, and the device endurance time is prolonged. In terms of timing isolation and security protection, two-level synchronization registers are deployed between static and dynamic modules for clock domain crossing (CDC) processing. A 15 % timing margin is reserved to isolate the influence of dynamic updating on timing and avoid timing violations caused by module updating, thereby ensuring the system reliability of mobile devices in complex application scenarios.

[0052] It can be understood that, compared with the traditional method, the verification time of the module (such as the algorithm updating of the NPU) that needs to be frequently iterated can be shortened from several hours to several minutes or even seconds, which greatly improves the verification efficiency.

[0053] In some embodiments of the present application, S103 can be implemented through S201-S203, as follows: S201, in the dynamic module hot updating mode, determining an error type; wherein the error type includes a logic error, and / or a data parameter error.

[0054] S202, based on the logic error and / or the data parameter error, determining an error repair method corresponding to the error type.

[0055] S203, repairing the error type according to the error repair method corresponding to the error type, to obtain a repaired file.

[0056] In some embodiments of the present application, if the error type is a logic error, it is determined that the error repair method corresponding to the logic error is a partial dynamic reconfiguration mode; if the error type is a data parameter error, it is determined that the error repair method corresponding to the data parameter error is an SRAM hot patch mode; and if the error type is a logic error and a data parameter error, it is determined that the error repair methods corresponding to the logic error and the data parameter error are the partial dynamic reconfiguration mode and the SRAM hot patch mode.

[0057] In some embodiments of the present application, a dual-mode non-interruption hot updating technology is used to solve errors. The technology combines the dynamic simulation principle of digital twinning in the "meta universe technology", and realizes the completion of verification configuration updating without interrupting the system operation.

[0058] For example, when it is detected that the RTL logic or data of the dynamic module needs to be corrected, the hot update without interruption is realized by any of the following ways: Partial dynamic reconfiguration mode: the differential bitstream is generated by using the incremental compilation function of the FPGA development tool, and the differential bitstream only contains the configuration difference of the dynamic module, which is loaded to the specified reconfiguration area of the FPGA through the debugging interface.

[0059] For example, logic error repair (dynamic reconfiguration): for logic errors, the partial dynamic reconfiguration (PR) mode of the FPGA is adopted. By using the mobile terminal adapted EDA tool, the differential bitstream (typical size <1MB) is generated by using the design checkpoint (DCP) technology. Through the debugging interface (such as USB or wireless), the differential bitstream is loaded to the specified reconfiguration area (PRR) of the FPGA within <1 second, realizing the nearly imperceptible logic update, and ensuring that the user experience is not affected when using the key application (such as taking pictures, video call).

[0060] (2) SRAM hot patch mode: a hexadecimal (Hex) file is generated by using a compilation tool, which is converted into a COE file by a script and bound to the IP core of the FPGA, or the Hex file is directly written into the address mapping area in the SRAM of the SoC through the ICP debugging interface.

[0061] For example, data parameter repair (SRAM hot patch): for data parameter errors, the SRAM hot patch mode is adopted. The Hex file is generated by using Keil compilation, which is converted into a memory initialization file (such as COE format) by a Perl script. Through the DMA channel of the debugging interface, the address mapping area in the internal SRAM of the FPGA is written at a speed of up to 100 MB / s, and the memory protection unit (MPU) technology is used to ensure the update safety. This way can modify the register value or memory content in real time, for example, the weight parameter or configuration parameter of the AI model, and the update speed can reach milliseconds.

[0062] The system state is monitored in real time through the UART, and the automatic closed-loop verification process is triggered: if it is a logic error, the partial dynamic reconfiguration mode of step (1) is returned; if it is a data parameter error, the SRAM hot patch mode of step (2) is returned.

[0063] It can be understood that, compared with the traditional update mode of generating a full bitstream, the present application only updates the error module, so that the update time can be shortened by more than 95%, and the waiting time of the verification process is significantly reduced.

[0064] In some embodiments of the present application, the method further comprises: If the error type is a logic error, the incremental compilation and differential bitstream loading of the mobile terminal EDA tool are automatically triggered to process the logic error; If the error type is a data parameter error, a script is called to regenerate configuration data to fix the data parameter error. In the case of completing the repair of logical errors or repairing data parameter errors, the key function regression test is automatically performed.

[0065] In some embodiments of the application, the tool chain deep collaboration and closed-loop verification are based on a joint simulation verification platform of System Verilog (G06F30 / 27) transaction level modeling (TLM). The MIF file is mapped to the IP core initialization memory through the $readmemh system task of the simulation tool (such as lightweight Verdi / VCS) adapted for mobile terminals. The parallel test framework driven by Makefile and the orthogonal experimental design (OED) method are used to realize the automatic regression test coverage of more than 90% of the design boundary conditions. The intelligent error diagnosis system relies on the serial data stream parser based on regular expressions, the random forest classification model, and the design constraint network (DCN) root cause analysis engine to extract abnormal features and locate error sources in real time. The closed-loop correction process automatically triggers the incremental compilation and differential bitstream loading of the mobile EDA tool to handle logical errors, or calls a script to regenerate configuration data to fix data errors, and automatically performs key function regression tests after updating. The tool chain deep collaboration and closed-loop verification mechanism are adopted in the application: multiple tools such as System Verilog (TLM), Verilog, Perl, Python, Keil, Vivado, etc. are integrated to build a joint simulation verification platform based on transaction level modeling (TLM).

[0066] Automatic process: The parallel test framework driven by Makefile and the orthogonal experimental design (OED) method are used to realize the automatic regression test coverage of more than 90% of the design boundary conditions.

[0067] Intelligent diagnosis and repair: The serial data stream parser based on regular expressions, the random forest classification model, and the design constraint network (DCN) root cause analysis engine are integrated to extract abnormal features and locate error sources in real time. The closed-loop correction process automatically triggers the incremental compilation and differential bitstream loading of the mobile EDA tool to handle logical errors, or calls a script to regenerate configuration data to fix data errors, and automatically performs key function regression tests after updating.

[0068] Efficient error location: By setting breakpoints, single-step tracing key modules, or using the Verilog system task $display to output error information in the Verdi waveform interface, the problem can be quickly located to a specific module and code line, reducing the error location time by about 30%-50%.

[0069] The system deploys a primary and backup dual configuration partition in the embedded flash memory of the mobile device, and cooperates with the hardware watchdog timer to realize an abnormal rollback recovery of <500ms, ensuring the high availability of the mobile intelligent terminal.

[0070] It can be understood that the system deploys a primary and backup dual configuration partition in the embedded flash memory of the mobile device, and cooperates with the hardware watchdog timer to realize an abnormal rollback recovery of <500ms, ensuring the high availability of the mobile intelligent terminal. The scheme integrates dynamic updating, intelligent diagnosis and closed-loop verification, is based on the SoC design, FPGA technology, EDA tool, storage technology and other branches in the key digital technology patent classification system, reduces 75% of the comprehensive time and 3-4 times of iteration of the traditional method, improves the verification efficiency and the success rate of streaming, makes up for the limitations of software simulation, and effectively enhances the performance and stability of the high-end chip of the mobile intelligent terminal.

[0071] The application provides a mobile intelligent terminal SoC prototype verification system and method based on FPGA partial dynamic reconfiguration and multi-mode hot update mechanism. The scheme innovatively integrates hardware dynamic reconfiguration technology, multi-modal hot update strategy, and automated intelligent diagnosis feedback closed loop to cope with the core challenges in complex SoC verification. The system relies on the core technology framework in the mobile intelligent terminal and artificial intelligence field in the Key Digital Technology Patent Classification System (2023), and builds a complete software and hardware collaborative verification system integrating hardware operation subsystem and software operation subsystem. Through the innovative integration of modular dynamic division strategy, dual-mode hot loading update mechanism and automated closed-loop verification process, the verification efficiency and system reliability of the mobile intelligent terminal complex SoC chip are significantly improved.

[0072] The hardware operation subsystem integrates low-power FPGA prototype verification development board, Xilinx Vivado design suite, Xilinx FPGA programmer and other key devices, and strictly follows the hardware specifications of the mobile intelligent terminal chip technology branch in the classification system. Considering the strict requirements of mobile intelligent terminals on power consumption and volume, the selected FPGA development board has the characteristics of low power consumption and small size. In specific implementation, for the RTL design of the mobile intelligent terminal SoC, in the FPGA RTL synthesis environment based on Vivado, the design processes such as logic synthesis and physical implementation (including layout and wiring) are completed in turn, and finally the bitstream file conforming to the Xilinx FPGA configuration standard is generated. With the help of the FPGA development board adapting to the interface of the mobile intelligent terminal (such as USB-Type C interface), the bitstream file is downloaded to the FPGA device, realizing the prototype deployment of the mobile intelligent terminal SoC system on the FPGA platform. This process is deeply related to the chip manufacturing and packaging test link in the "mobile intelligent terminal chip technology" in the classification system, especially the technical specifications of low-power FPGA / CPLD chips.

[0073] The software operation subsystem integrates the Cadence Verdi / VCS simulation suite, the ARM Keil MDK development environment, the ICP debug interface module, and a wireless UART monitoring unit suitable for mobile smart terminals, strictly adhering to the software technology requirements for EDA tools and mobile smart terminal chip design in the classification system. Specifically, the Verdi / VCS simulation suite performs functional-level co-simulation verification of the RTL design of mobile smart terminal SoCs based on machine learning and pattern recognition algorithms in the "General Artificial Intelligence Technology" category; the Keil MDK development environment cross-compiles assembly language programs and C language test programs according to the logic chip programming specifications in "Mobile Smart Terminal Chip Design"; the ICP debug interface module acts as a bridge between the Keil development environment and the FPGA verification platform, following the interface protocol standards in "Packaging and Testing" to complete the programming of Hex format executable files to the SoC's on-chip SRAM; and the wireless UART module collects and transmits system operating status data in real time, referencing the monitoring mechanism of the "Mobile Internet Security Layer" to achieve full lifecycle monitoring and management of the high-end chip verification system for mobile smart terminals, facilitating developers to remotely view system status in mobile scenarios.

[0074] To more clearly demonstrate the application of the technical solution of this application in the verification of high-end chips for mobile intelligent terminals, the following is combined with... Figures 2-6 The specific implementation method of the SOC chip prototype verification platform based on FPGA dynamic reconfigurable architecture is described in detail below: I. FPGA RTL Synthesis and Module Partitioning System (PC) The system architecture of a high-end chip prototype verification platform for mobile smart terminals based on FPGA, such as Figure 2 As shown, the system includes an FPGA RTL synthesis device and an FPGA prototyping platform. The core of this system is a PC equipped with the Xilinx Vivado design kit, which establishes a physical connection with the FPGA verification board via a dedicated download cable. The system incorporates a dynamic module intelligent partitioning engine developed based on Python scripts. This engine, targeting the complex heterogeneous characteristics of high-end SoC chips for mobile smart terminals, employs timing critical path analysis (TCPA) and functional coupling quantification evaluation algorithm models to achieve precise partitioning of SoC design modules. Static module deployment (system-level basic functions): Modules crucial to the overall system stability of the mobile smart terminal SoC, such as the clock management unit (MMCM / PLL), high-speed serial interfaces (e.g., MIPI, PCIe), and power management module (PMU), which are highly coupled units, are fixedly placed in the Bank0-3 area of ​​the FPGA. This ensures the basic timing stability of the entire prototype system (e.g., a simulated Android environment) during operation.

[0075] Dynamic module configuration (application processor and accelerator): For modules with frequent function iterations in mobile intelligent terminal SoCs, such as state machines (FSMs) of application processors (CPUs), algorithm modules (such as FFTs) in AI acceleration cores (NPUs) or image signal processors (ISPs), and low-coupling modules such as configuration register groups, the modules are allocated to a part of the reserved reconfigurable region (PRR) (physical region X0Y120 to X50Y180) of the FPGA to support dynamic logic updating without interrupting system operation.

[0076] The system finally generates a full bitstream (full.bit) for initial configuration of the FPGA, and a differential bitstream (partial.bit) for subsequent "hot updating", and stores them under the / vivado_prj / project_1.runs / impl_1 path.

[0077] It should be noted that, Figure 2 Vivado in the above is an FPGA software tool of the xilinx company, which is used to compile chip design code (RTL) into a program (bitstream file) that can run on the FPGA, and can also modify a certain module separately to generate a small patch (differential bitstream) for direct updating. Keil is an IDE integrated development environment software, which is used to write and compile software programs (C / assembly code) for testing chips to generate executable files (Hex), and can also directly modify data in the chip memory (such as parameter tuning). Vcs / Verdi is an EDA tool of synopsys company, which is used to simulate chip operation on computer, check design for problems in advance, and can analyze where the signal is wrong. Uart is a universal asynchronous serial interface, which is used to monitor the running state of the chip in real time, print error information (such as error codes 0xE1, 0xE2), and help to determine whether it is a hardware logic problem or a data problem. Figure 1

[0078] II. Software verification and debugging system (PC end) This system integrates Keil development environment, serial debugging tool and Cadence Verdi / VCS joint simulation suite, and interacts with the hardware prototype through the debugging SGW emulator and UART-to-USB line, and focuses on the software and hardware co-verification of mobile SoC: Code compilation: cross-compile the assembly test code and C language program of the underlying driving firmware (Firmware) using Keil to generate Intel Hex format files that adapt to the hardware verification requirements.

[0079] ​Joint simulation: In the Verdi / VCS environment, the C_INIT_FILE_NAME signal of the SRAM IP core generated by Vivado is associated with the MIF file to build a hardware-software co-simulation platform. This allows software engineers to develop and debug NPU drivers or ISP firmware in advance on the hardware behavior level model and perform coverage-driven verification.

[0080] Data conversion: Hex to COE format conversion is realized through a Perl script (path / scripts / hex2coe.pl) to meet the data initialization format requirements of the FPGA internal BRAM / SRAM module.

[0081] Debugging transmission: The ICP debugger realizes high-speed data transmission of ≥10 MB / s based on DMA technology for fast loading of test cases or reading memory; the UART-to-USB module collects debugging information in real time and supports monitoring of the running state of mobile intelligent terminal SoCs.

[0082] III. FPGA hardware verification platform This platform uses Xilinx Artix-7 XC7A200T-2FBG484I FPGA as the core to simulate the hardware environment of mobile intelligent terminal SoCs, with the following configurations: Storage system: Dual-Bank SPI Flash (Micron N25Q128A) is integrated to store A / B dual configuration bitstreams of stable and development versions, ensuring quick rollback in case of update failure, which is crucial for system-level verification running for a long time.

[0083] Interface configuration: Standard JTAG interface connects FPGA configuration pins (Bank0) to support bitstream download and hardware-level debugging.

[0084] Data storage: FPGA internal SRAM mapping address space is reserved for storing hot patch data that needs to be dynamically modified at runtime, such as AI model weight parameters or ISP calibration parameters.

[0085] Timing guarantee: Three-level synchronization registers are deployed between static and dynamic modules, and handshaking mechanism is used to handle clock domain crossing (CDC), with 15% timing margin reserved to physically isolate the timing impact of dynamic update process on other stable running modules of SoC (such as DDR controller).

[0086] IV. Module division rules and verification process Dynamic threshold division strategy: This strategy is optimized for RTL design of large mobile intelligent terminal high-end chips. For example, Figure 3As shown, starting from the complete mobile intelligent terminal SoC RTL design, recursive modular division is adopted, and the initial coupling degree threshold is 30%: the first-level division generates static module 1 (including the clock network, high-speed interface and other infrastructure of the entire mobile intelligent terminal SoC) and dynamic module 1, and static module 1 is fixed to FPGA1; the threshold of each subsequent level is dynamically calculated according to 85% of the previous level (such as 25.5% for the second level and 21.7% for the third level), and the newly divided static module is deployed to FPGA2-FPGAn in turn, while the dynamic module is continuously iteratively divided until the resource and timing termination conditions of the reconfigurable area are met.

[0087] Prototype verification workflow: Hardware configuration: full compilation generates base.bit, and dynamic update generates diff.bit through incremental compilation, which is downloaded to the FPGA prototype via JTAG.

[0088] Software configuration: compile the test program for a specific module (such as NPU) in Keil, configure its stack pointer and interrupt vector table. In the Linux environment, Hex to COE conversion is completed through a Perl script, and then the test data is adapted to the memory initialization file of the FPGA using a Vivado script.

[0089] Joint verification: associate MIF files in the Verdi environment to start simulation and generate coverage report coverage.html. If the verification is passed, proceed to the next dynamic verification; otherwise, trigger the corresponding repair process according to the error type.

[0090] Dual-mode hot update mechanism: This mechanism is the core advantage of the present scheme, which can realize "online surgical" repair of the mobile intelligent terminal SoC prototype without restarting the entire verification system.

[0091] As shown in Figure 4 , the ASIC RTL design is divided into static modules and dynamic modules. The dynamic hot update mode is selected; logic errors use partial dynamic reconstruction, and data errors (i.e. data parameter errors) use sram hot patching.

[0092] Logic bug fix (online update algorithm / logic): When the UART returns error code 0xE1 (for example, NPU inference result error), trigger the logic bug fix process. At this time, execute the fpga_update -partialdiff.bit command through the ICP interface to load the differential bitstream containing the corrected logic. With the help of FPGA dynamic reconfiguration technology, the NPU or ISP algorithm core can be quickly updated in ≤1 second, ensuring the continuity of the verification business of the application layer (such as AI camera). This process perfectly fits the application of dynamic reconfigurable chip technology in high-end chip verification.

[0093] Data bug fix (online parameter modification): When the UART returns error code 0xE2 (for example, some configuration parameter in memory is wrong), use the Memory window of the Keil development environment to execute commands such as mem_write -addr 0x2000FF00 -data 0x1234 through the ICP debug emulator in DMA mode to directly modify the error data and parameters in the SRAM address space. This operation belongs to the category of "memory operation and data correction" in high-end chip technology, and is extremely efficient for debugging mobile intelligent terminal SoC modules that require a large number of parameter configurations (such as display controllers or sensor hubs).

[0094] Closed-loop safety verification system: In order to ensure the stability of the long-time verification process, the platform introduces a closed-loop safety verification system: A watchdog module (watchdog.v) is used to monitor the system heartbeat signal (such as the tick of the operating system kernel) in real time, and a 500ms timeout threshold is set. When the system encounters an abnormality such as deadlock due to logic update failure or other reasons, the watchdog will automatically trigger the A / B Bank switching instruction reset_config -bankB to make the FPGA prototype quickly recover to the last stable baseline version. This mechanism meets the high reliability requirements of mobile terminals and ensures the safe and stable operation of the entire verification platform.

[0095] Software operation specific steps: In the Keil MDK development environment, select the device model as the ARMCortex-M series microcontroller core inside the simulated mobile intelligent terminal SoC (such as Device: Generic Cortex-M3), which is commonly used in sensor coprocessors or security subsystems inside mobile intelligent terminal SoCs.

[0096] Set the link script (sram.ld) to specify the starting address and memory layout of the firmware (Firmware) code in the FPGA prototype SRAM.

[0097] The assembly code and C language test program of the underlying driver are translated and built using the corresponding compiler to generate a hex file. This process belongs to the "firmware generation and compilation" link in the high-end mobile intelligent terminal SoC design process.

[0098] The generated hex file is copied to the Linux workstation.

[0099] It is converted into a coe file by a Perl script to adapt to the initialization format of the FPGA internal Block RAM. This meets the technical requirements of the "data format adaptation" in the mobile intelligent terminal SoC design process.

[0100] The coe file is imported into the Vivado software as the initialization data of the specific IP core (such as the instruction SRAM of the NPU) in the mobile intelligent terminal SoC.

[0101] The corresponding MIF file and two IP core simulation model.v files are generated.

[0102] The relevant files are copied to the Linux system of the FPGA prototype verification platform, and they are instantiated into the RTL code of the top-level design of the mobile intelligent terminal SoC.

[0103] The C_INIT_FILE_NAME signal of the simulation model top-level file is associated with the MIF file address, completing the "IP core integration and system modeling", and building a hardware prototype that can be simulated and contains software behavior.

[0104] Run the Makefile script under the Linux system to perform Verdi / VCS joint simulation of the entire mobile intelligent terminal SoC design.

[0105] In the Verdi waveform interface, you can set breakpoints (such as bfir_filter.v:120) for key modules of the ISP (image signal processor) and single-step trace the internal state machine jump.

[0106] If the simulation fails, you can output the error address and data through the Verilog system task $display("ERROR: SRAM[%h]=%h", addr, rdata) to quickly locate the problem. This corresponds to the "hardware simulation and fault diagnosis" branch in high-end chip technology.

[0107] In Keil, the ICP debug interface is connected to the simulated mobile intelligent terminal SoC program download interface on the FPGA verification board through the solidified software.

[0108] After the test is successful, the program is downloaded to the SRAM in the mobile intelligent terminal SoC system, and the SOC prototype verification is formally carried out.

[0109] During the verification process, the UART monitors the output in real time and matches the abnormal features based on regular expressions: Logical errors (such as inconsistent NPU inference results): After calling the Vivado Tcl script pr_verify -full_checkpoint base.dcp -partial partial.bit to verify the compatibility of the differential bitstream, the "logical hot update" is implemented.

[0110] Data errors (such as GPU configuration parameter errors): Correct data is written to SRAM in batches through the DMA engine of the ICP interface, and "memory data correction" is completed.

[0111] As shown in Figure 5 , this scheme is based on standardized design processes and innovative hardware configuration strategies for mobile intelligent terminal SoCs, achieving efficient hardware prototype verification on the FPGA platform. The specific implementation steps are as follows: For the RTL design of the target mobile intelligent terminal SoC, carry out FPGA architecture adaptation optimization.

[0112] Focus on completing the migration and adaptation of clock modules (Clocking Wizard), reset logic (ProcessorSystem Reset), memory units (such as DDR controllers), and GPIO interfaces in mobile intelligent terminal SoCs.

[0113] By replacing the dedicated hard-core units (such as custom PLLs) in SOC design with equivalent IP cores in FPGA, a register transfer level design that matches the hardware characteristics of FPGA is constructed, laying the foundation for subsequent system-level verification.

[0114] Based on the physical resources of FPGA, a static-dynamic partitioning strategy is adopted for modular layout planning of mobile intelligent terminal SoCs, and precise layout is achieved through Vivado Tcl commands: Static module solidification: Use commands such as set_property PACKAGE_PIN AE12 [get_cells clk_wiz] to fix key modules such as clock management, high-speed interfaces (such as MIPI D-PHY) in mobile intelligent terminal SoCs at specified physical locations, ensuring the timing stability of the prototype system's basic functions.

[0115] Dynamic region reservation: By commands such as define_pblock PR_Region -rect {10 10 50 50}, a part of the reconfigurable region (Partial Reconfiguration Region) is divided for NPU, ISP and other modules that need to frequently iterate algorithms, providing hardware resource support for logical dynamic update.

[0116] As shown in Figure 6 , a complete constraint file system is built for the mobile intelligent terminal SoC prototype, including timing constraints and pin physical constraints: Timing constraints: Based on the timing requirements of SOC design (such as CPU frequency, DDR read-write timing), combined with the characteristics of FPGA, parameter adaptation is completed, the accuracy of signal transmission timing is ensured by optimizing the delay of the critical path.

[0117] Pin physical constraints: Accurately allocate the external ports of SoC (such as USB, SDIO) to the FPGA development board pins to meet the electrical characteristics requirements, improve signal integrity and reduce electromagnetic interference (EMI) risk. The two types of constraints work together to achieve the comprehensive optimization of design correctness, performance power consumption and reliability.

[0118] Import the optimized SoC RTL code of the mobile intelligent terminal and the constraint file into the Vivado design suite.

[0119] Perform logic synthesis, layout and routing processes in sequence to generate full bitstream files (FullBitstream) for initialization and differential bitstream files (Differential Bitstream) for hot updating.

[0120] Burn the bitstream to the FPGA chip through the JTAG interface to complete the hardware prototype deployment of the mobile intelligent terminal SoC design.

[0121] Build a dual-bank redundant storage architecture to improve the security and fault tolerance of the mobile intelligent terminal SoC verification process: Version management: Bank A stores a stable baseline version bitstream (base.bit), and Bank B stores the current development version to be verified (test.bit). The switching can be triggered by GPIO buttons (for example, when switches[0]=1’b1, Bank B is loaded), which facilitates quick switching and comparison between different functional versions.

[0122] State maintenance: before dynamic update, the key register states (such as PMU configuration, interrupt controller state) in the mobile intelligent terminal SoC are backed up to BRAM by using the reg_save -file backup.reg command. If the verification is abnormal and the system crashes, the system context can be quickly restored by using the reg_restore -file backup.reg instruction, forming a safe closed-loop management of the verification process.

[0123] Based on the FPGA partial dynamic reconfiguration-based intelligent terminal SoC prototype verification method of the above embodiment, an FPGA partial dynamic reconfiguration-based intelligent terminal SoC prototype verification system is further provided, as shown in Figure 7 Figure 7 A structure diagram of the FPGA partial dynamic reconfiguration-based intelligent terminal SoC prototype verification system provided by the embodiment of the present application is shown in the figure. The FPGA partial dynamic reconfiguration-based intelligent terminal SoC prototype verification system 7 comprises an acquisition module 701, a generation module 702, a selection module 703, a determination module 704, and a verification module 705, wherein The acquisition module 701 is configured to acquire a pre-determined dynamic module and a static module; wherein the dynamic module and the static module are obtained by self-adaptively dividing the hardware resources of the mobile intelligent terminal chip; The generation module 702 is configured to perform prototype joint verification based on the dynamic module and the static module, and generate a coverage report; The selection module 703 is configured to select a dynamic module hot update mode if the coverage report indicates that there is an error; The determination module 704 is configured to determine an error type in the dynamic module hot update mode, and perform error repair according to the error type to obtain a repaired file; The verification module 705 is configured to perform joint simulation and system running verification based on the repaired file, and obtain a verification result of the mobile intelligent terminal SoC prototype.

[0124] In some embodiments of the present application, the acquisition module 701 is further configured to acquire a plurality of functional modules of the register transfer level of the mobile intelligent terminal SoC to be verified before acquiring the pre-determined dynamic module and the static module; The determination module 704 is further configured to calculate the coupling degree of each of the plurality of functional modules; for the coupling degree of each of the plurality of functional modules, if the coupling degree of the each functional module is greater than a preset coupling degree, the each functional module is determined as the static module; if the coupling degree of the each functional module is less than or equal to the preset coupling degree, the each functional module is determined as the dynamic module.​

[0125] In some embodiments of the present application, the determining module 704 is further configured to determine, for each function module of the plurality of function modules, a number of signal interactions of the each function module with other function modules; determine a total number of modules of the plurality of function modules; and calculate, based on the number of signal interactions of the each function module with other function modules and the total number of modules of the plurality of function modules, a coupling degree of the each function module, to obtain respective coupling degrees of the plurality of function modules.

[0126] In some embodiments of the present application, the static module is fixed in a bit stream of an FPGA, and includes fixed logic of a clock network, a high-speed interface, or a hardware accelerator of a mobile intelligent terminal SoC; the static module is merged into a single bit stream, and only needs full compilation when it is synthesized for the first time; the dynamic module supports runtime updating, and includes state machine jump logic of a processor core, algorithm parameters of an AI accelerator, or a register configuration table of a GPU.

[0127] In some embodiments of the present application, the determining module 704 is further configured to determine, in the dynamic module hot updating mode, an error type; wherein the error type includes a logic error and / or a data parameter error; determine, based on the logic error and / or the data parameter error, an error repair method corresponding to the error type; and repair the error type according to the error repair method corresponding to the error type, to obtain a repaired file.

[0128] In some embodiments of the present application, the determining module 704 is further configured to, if the error type is the logic error, determine that a partial dynamic reconstruction mode is the error repair method corresponding to the logic error; if the error type is the data parameter error, determine that an SRAM hot patch mode is the error repair method corresponding to the data parameter error; and if the error type is the logic error and the data parameter error, determine that the partial dynamic reconstruction mode and the SRAM hot patch mode are the error repair methods corresponding to the logic error and the data parameter error.

[0129] In some embodiments of the present application, the verifying module 705 is further configured to, if the error type is a logic error, automatically trigger an incremental compilation and a differential bit stream loading of a mobile terminal EDA tool to process the logic error; if the error type is a data parameter error, call a script to regenerate configuration data to repair the data parameter error; and automatically perform a key function regression test after the repair of the logic error or the repair of the data parameter error.

[0130] Based on the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification method of the above embodiment, an FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification device is further provided in the embodiment of the application, as shown in Figure 8 Figure 8 A structural schematic diagram of the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification device provided in the embodiment of the application is shown in the figure, which includes a processor 801 and a memory 802. The memory 802 is configured to store a computer program, and the processor 801 is configured to call and run the computer program from the memory to perform the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification method as described in the above embodiment.

[0131] In the embodiment of the application, the processor 801 can be at least one of an application specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, and a microprocessor. It can be understood that, for different devices, the electronic device for implementing the function of the processor can also be other devices, and the embodiment of the application is not limited in this regard.

[0132] The embodiment of the application provides a computer readable storage medium, which stores a computer program, and is configured to implement the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification method as described in any of the above embodiments when executed by a processor.

[0133] For example, the program instructions corresponding to the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification method in the embodiment of the application can be stored on a storage medium such as an optical disc, a hard disk, a U disk, etc. When the program instructions corresponding to the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification method in the storage medium are read by an electronic device or executed, the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification method as described in any of the above embodiments can be implemented.

[0134] ​In addition, each functional module in the embodiments of the present application can be integrated in one processing unit, or each unit can exist independently physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware, or in the form of software function module.

[0135] When the integrated unit is realized in the form of software function module and is not sold or used as an independent product, the integrated unit can be stored in a computer readable storage medium, based on such understanding, the technical solutions of the embodiments essentially or the part of the prior art that contributes to the technical solutions or the whole or part of the technical solutions can be embodied in the form of software product, the computer software product is stored in a storage medium, includes a plurality of instructions to make a computer device (may be a personal computer, server, or network device, etc.) or processor (processor) execute all or part of the steps of the embodiments method. And the foregoing storage medium includes: U disk, mobile hard disk, read only memory (Read Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and various program codes that can be stored in the medium.

[0136] It should be understood that the "one embodiment" or "an embodiment" or "some embodiments" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiments are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" or "in some embodiments" appearing throughout the specification does not necessarily mean the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the sequence number of the above processes does not mean the execution order, the execution order of the processes should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above sequence number of the embodiments of the present application is only for description, not representing the advantages and disadvantages of the embodiments. The above description of each embodiment tends to emphasize the differences between each embodiment, and the same or similar parts can be referred to each other, for the sake of brevity, which will not be repeated here.

[0137] The above modules described as separate components can or can not be physically separated, and the components displayed as modules can or can not be physical modules; they can be located in one place or distributed on multiple network units; part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0138] In addition, each functional module in the embodiments of the present application can be integrated in one processing unit, or each module can be separately single as a unit, or two or more modules can be integrated in one unit; the integrated module can be realized in the form of hardware, or in the form of hardware plus software function unit.

[0139] Those skilled in the art can understand that all or part of the steps of the above method embodiments can be completed by program instruction related hardware, and the foregoing program can be stored in a computer readable storage medium, and the program executes the steps of the method embodiments when executed; and the foregoing storage medium includes a mobile storage device, a read only memory (Read Only Memory, ROM), a magnetic disc or an optical disc, and various storage medium capable of storing program codes.

[0140] The methods disclosed in the several method embodiments provided by the embodiments of the present application can be combined arbitrarily without conflict to obtain new method embodiments.

[0141] The features disclosed in the several product embodiments provided by the embodiments of the present application can be combined arbitrarily without conflict to obtain new product embodiments.

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

[0143] The above is only the implementation manner of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited to this, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be covered in the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application should be subject to the protection scope of the claims.

Claims

1. A method for SoC prototype verification of intelligent terminal based on FPGA partial dynamic reconfiguration, characterized in that, The method comprises: acquiring a predetermined dynamic module and a static module; wherein the dynamic module and the static module are obtained by self-adaptively dividing hardware resources of a mobile intelligent terminal chip; based on the dynamic module and the static module, performing prototype joint verification to generate a coverage report; if the coverage report indicates that there is an error, selecting a dynamic module hot update mode; in the dynamic module hot update mode, determining an error type; and according to the error type, performing error repair to obtain a repaired file; based on the repaired file, performing joint simulation and system running verification to obtain a verification result of a mobile intelligent terminal SoC prototype.

2. The method of claim 1, wherein, Before the acquiring a predetermined dynamic module and a static module, the method further comprises: acquiring a plurality of functional modules of a register transfer level of a mobile intelligent terminal SoC to be verified; calculating a coupling degree corresponding to each of the plurality of functional modules; for the coupling degree of each of the plurality of functional modules, if the coupling degree of the each of the plurality of functional modules is greater than a preset coupling degree, the each of the plurality of functional modules is determined as the static module; if the coupling degree of the each of the plurality of functional modules is less than or equal to the preset coupling degree, the each of the plurality of functional modules is determined as the dynamic module.

3. The method of claim 2, wherein, The calculating a coupling degree corresponding to each of the plurality of functional modules comprises: for each of the plurality of functional modules, determining a signal interaction number of the each of the plurality of functional modules and other functional modules; determining a total number of the plurality of functional modules; based on the signal interaction number of the each of the plurality of functional modules and other functional modules and the total number of the plurality of functional modules, calculating the coupling degree of the each of the plurality of functional modules to obtain the coupling degree corresponding to each of the plurality of functional modules.

4. The method of any one of claims 1-3, wherein: the static module is fixed in a bit stream of an FPGA, and includes fixed logic of a clock network, a high-speed interface, or a hardware accelerator of the mobile intelligent terminal SoC; the static module is merged into a single bit stream, and only needs full compilation when first synthesized; the dynamic module supports runtime updating, and includes state machine jump logic of a processor core, algorithm parameters of an AI accelerator, or a register configuration table of a GPU.

5. The method of claim 1, wherein, The determining an error type in the dynamic module hot update mode, and performing error repair according to the error type to obtain a repaired file, comprises: in the dynamic module hot update mode, determining the error type; wherein the error type includes a logic error and / or a data parameter error; based on the logic error and / or the data parameter error, determining an error repair mode corresponding to the error type; according to the error repair mode corresponding to the error type, repairing the error type to obtain the repaired file. If the error type is the logic error, the error repair mode corresponding to the logic error is determined as a partial dynamic reconstruction mode.

6. The method of claim 5, wherein, ​ ​ If the error type is the data parameter error, it is determined that the error repair mode corresponding to the data parameter error is an SRAM hot patch mode. If the error type is the logic error and the data parameter error, it is determined that the error repair mode corresponding to the logic error and the data parameter error is a partial dynamic reconfiguration mode and an SRAM hot patch mode.

7. The method of claim 1, wherein, The method further comprises: If the error type is a logic error, triggering an incremental compilation and a differential bitstream loading of a mobile EDA tool to automatically repair the logic error; If the error type is a data parameter error, calling a script to regenerate configuration data to repair the data parameter error; In the case of completing the repair of the logic error or repairing the data parameter error, automatically performing a critical function regression test.

8. An intelligent terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration, characterized in that, The FPGA-based partial dynamic reconfiguration intelligent terminal SoC prototype verification system comprises an acquisition module, a generation module, a selection module, a determination module and a verification module, wherein, The acquisition module is configured to acquire a predetermined dynamic module and a static module, wherein the dynamic module and the static module are obtained by self-adaptively dividing hardware resources of a mobile intelligent terminal chip; The generation module is configured to generate a coverage report by performing prototype joint verification based on the dynamic module and the static module; The selection module is configured to select a dynamic module hot update mode if the coverage report indicates that there is an error; The determination module is configured to determine an error type in the dynamic module hot update mode, and perform error repair according to the error type to obtain a repaired file; The verification module is configured to perform joint simulation and system running verification based on the repaired file to obtain a verification result of a mobile intelligent terminal SoC prototype.

9. An intelligent terminal SoC prototype verification device based on FPGA partial dynamic reconfiguration, characterized in that, comprise: a processor and a memory, wherein the memory is configured to store a computer program; the processor is configured to call and run the computer program from the memory to execute the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, executable instructions are stored, which cause the processor to implement the method of any one of claims 1 to 7 when executed.

Images