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

Abstract

The embodiment of the application provides a kind of based on FPGA partial dynamic reconfiguration's intelligent terminal SoC prototype verification method and system, this method includes: obtaining predetermined dynamic module and static module;Wherein, dynamic module and static module are obtained by self-adapting division to the hardware resource of mobile intelligent terminal chip;Based on dynamic module and static module, prototype joint verification is carried out, and coverage report is generated;If coverage report represents that there is error, then dynamic module hot update mode is selected;In dynamic module hot update mode, error type is determined;And according to error type, error repair is carried out, and the file after repair is obtained;Based on the file after repair, joint simulation and system running verification are carried out, and the verification result of mobile intelligent terminal SoC prototype is obtained.The above scheme can improve the verification efficiency of intelligent terminal SoC prototype.

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 function 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 a function module, 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 discover and optimize power consumption bottlenecks 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:

[0005] 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:

[0006] 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;

[0007] 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, a dynamic module hot update mode is selected;

[0008] In the dynamic module hot update mode, a type of error is determined, and error repair is performed according to the type of error to obtain a repaired file.

[0009] 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.

[0010] In the above scheme, before the predetermined dynamic module and static module are obtained, the method further comprises:

[0011] A plurality of functional modules of a register transfer level of the mobile intelligent terminal SoC to be verified are obtained.

[0012] The coupling degree corresponding to each of the plurality of functional modules is calculated.

[0013] 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.

[0014] 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.

[0015] In the above scheme, the calculation of the coupling degree corresponding to each of the plurality of functional modules comprises:

[0016] For each functional module in the plurality of functional modules, the number of signal interactions of each functional module with other functional modules is determined.

[0017] The total number of modules of the plurality of functional modules is determined.

[0018] Based on the number of signal interactions of each functional module with 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.

[0019] 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.

[0020] 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.

[0021] In the above scheme, in the dynamic module hot update mode, a type of error is determined, and error repair is performed according to the type of error to obtain a repaired file, which comprises:

[0022] 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;

[0023] Based on the logic error and / or the data parameter error, the error type corresponding error repair method is determined;

[0024] According to the error type corresponding error repair method, the error type is repaired to obtain the repaired file.

[0025] In the above scheme, the error type corresponding error repair method is determined based on the logic error and / or the data parameter error, comprising:

[0026] If the error type is the logic error, the logic error corresponding error repair method is determined as a partial dynamic reconstruction mode;

[0027] If the error type is the data parameter error, the data parameter error corresponding error repair method is determined as an SRAM hot patch mode;

[0028] If the error type is the logic error and the data parameter error, the logic error and the data parameter error corresponding error repair method is determined as a partial dynamic reconstruction mode and an SRAM hot patch mode.

[0029] In the above scheme, the method further comprises:

[0030] If the error type is a logic error, the incremental compilation and differential bit stream loading of the mobile EDA tool are automatically triggered to process the logic error;

[0031] If the error type is a data parameter error, a script is called to regenerate configuration data to repair the data parameter error;

[0032] In the case of completing the repair of the logic error or repairing the data parameter error, a key function regression test is automatically performed.

[0033] In a second aspect, the embodiments of the present application provide a smart terminal SoC prototype verification system based on FPGA partial dynamic reconstruction, comprising: an acquisition module, a generation module, a selection module, a determination module and a verification module, wherein,

[0034] 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;

[0035] The generating module is configured to perform prototype joint verification based on the dynamic module and the static module, and generate a coverage report;

[0036] The selecting module is configured to select a dynamic module hot updating mode if the coverage report indicates that there is an error.

[0037] The determining module is configured to determine an error type in the dynamic module hot updating mode, and perform error repair according to the error type to obtain a repaired file.

[0038] The verifying module is configured to perform joint simulation and system running verification based on the repaired file to obtain a verification result of the mobile intelligent terminal SoC prototype.

[0039] In a third aspect, an embodiment of the present application provides an intelligent terminal SoC prototype verification device based on FPGA partial dynamic reconstruction, comprising a processor and a memory, wherein,

[0040] The memory is configured to store a computer program.

[0041] The processor is configured to call and run the computer program from the memory to execute the method of the first aspect.

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

[0043] The embodiment of the present application provides a kind of based on FPGA partial dynamic reconfiguration intelligent terminal SoC prototype verification method and system, which comprises: obtaining the dynamic module and static module determined in advance;Wherein, the dynamic module and the static module are obtained by self-adaptive division to the hardware resource of mobile intelligent terminal chip;Based on the dynamic module and the static module, prototype joint verification is carried out, and coverage report is generated;If the coverage report represents error, dynamic module hot update mode is selected;In the dynamic module hot update mode, error type is determined;And according to the error type, error repair is carried out, and the repaired file is obtained;Based on the repaired file, joint simulation and system running verification are carried out, and the verification result of mobile intelligent terminal SoC prototype is obtained.In the above scheme, the dynamic module and the static module are obtained by self-adaptive division to the hardware resource of mobile intelligent terminal chip;Prototype joint verification is carried out to the dynamic module, and dynamic module hot update mode is selected if the coverage report obtained represents error;In the dynamic module hot update mode, according to the error type, error repair is carried out, and the repaired file is obtained, and joint simulation and system running verification are carried out to the repaired file, and the verification result of mobile intelligent terminal SoC prototype is obtained.Because the dynamic module and the static module are divided, after error occurs in the dynamic module, only the dynamic module with error is updated, so that the update time is shortened, and the waiting time of verification process is significantly reduced;At the same time, the verification time of dynamic module that needs to be iterated frequently is shortened from several hours to several minutes, even seconds, which greatly improves the verification efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0044] The drawings incorporated into the specification and forming part of the specification, these drawings show the embodiments consistent with the present application, and together with the specification, used to illustrate the technical solutions of the present application. Obviously, the drawings in the following description are only some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creating labor.

[0045] The flowchart shown in the drawings is only illustrative, not necessarily including all contents and operations / steps, and not necessarily executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so that the actual execution order may change according to the actual situation.

[0046] Figure 1 An optional flowchart of a kind of based on FPGA partial dynamic reconfiguration intelligent terminal SoC prototype verification method provided by the embodiment of the present application is shown in the following figure:

[0047] Figure 2A system architecture diagram of a high-end chip prototype verification platform of a mobile intelligent terminal based on FPGA is provided for the embodiment of the present application.

[0048] Figure 3 A dynamic and static module division rule diagram based on timing critical path analysis and functional coupling quantification evaluation is provided for the embodiment of the present application.

[0049] Figure 4 A general flowchart of the working of a prototype verification platform is provided for the embodiment of the present application.

[0050] Figure 5 A specific working step schematic diagram of the software part of a prototype verification platform is provided for the embodiment of the present application.

[0051] Figure 6 A specific working step schematic diagram of the hardware part of a prototype verification platform is provided for the embodiment of the present application.

[0052] Figure 7 A structure schematic diagram of a smart terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration is provided for the embodiment of the present application.

[0053] Figure 8 A structure schematic diagram of a smart terminal SoC prototype verification device based on FPGA partial dynamic reconfiguration is provided for the embodiment of the present application. DETAILED DESCRIPTION

[0054] 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.

[0055] 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.

[0056] In the following description, "some embodiments", "the embodiment", "the embodiment of the present application" and the like, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subset of all possible embodiments, and can be combined with each other without conflict.

[0057] If the application file contains similar descriptions of "first / second", the following description is added. In the following description, the terms "first / second / third" are only used to distinguish similar objects, and do not represent a specific order of the objects. Understandably, "first / second / third" can be interchanged in a specific order or sequence as allowed, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein.

[0058] 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 is provided for the embodiments of the present application, which will be described in combination with Figure 1 The steps shown will be described.

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

[0060] 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 parameters of the AI accelerator or the register configuration table of the GPU.

[0061] 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.

[0062] In some embodiments of the present application, the smart terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration is applicable to the smart terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration.

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

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

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

[0066] In the dynamic module hot update mode, the error type is determined, and the error is repaired according to the error type to obtain a repaired file.

[0067] 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, the error repair mode corresponding to the error type is determined; and the error type is repaired according to the error repair mode corresponding to the error type to obtain a repaired file.

[0068] In some embodiments of the present application, after the RTL is divided into a dynamic module and a static module, the dynamic module hot update mode is selected, and it is first determined 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.

[0069] 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.

[0070] 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.

[0071] 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) adapted to mobile terminals are used to accurately locate and modify a module, a difference bitstream (typically <1MB in size) containing logical differences is generated through a design checkpoint (DCP) technology, and the difference 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).

[0072] 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 memory protection unit (MPU) technology is used to ensure update safety.

[0073] 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.

[0074] 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.

[0075] 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 that there is an error in the obtained coverage report, the 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, after an error occurs in the dynamic module, only the dynamic module with the error is updated, 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.

[0076] In some embodiments of the present application, before S101 is performed, S105-S108 are further performed, as follows:

[0077] S105, a plurality of functional modules of a register transfer level of the mobile intelligent terminal SoC to be verified are obtained.

[0078] S106, calculate the coupling degree of each of the plurality of function modules.

[0079] In some embodiments of the present application, for each of 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; 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, the coupling degree of each function module is calculated, and the coupling degree of each of the plurality of function modules is obtained.

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

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

[0082] It should be noted that the coupling degree of each of the plurality of function modules is the coupling degree of each function module in the plurality of function modules. The coupling degree of each function module is 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 of the plurality of function modules, if the coupling degree of any one module is greater than the preset coupling degree, the any one module is determined as a static module.

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

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

[0085] It should be noted that the coupling degree of each of the plurality of function modules is the coupling degree of each function module in the plurality of function modules. The coupling degree of each function module is 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 of the plurality of function modules, if the coupling degree of any one module is less than or equal to the preset coupling degree, the any one module is determined as a dynamic module.

[0086] For example, in view of the strict requirements of mobile intelligent terminal high-end chips 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 mobile terminal chip technology branch. 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:

[0087] 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.

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

[0089] 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", the adaptive division of hardware resources is realized through the intelligent module division strategy (based on timing critical path analysis and functional coupling degree quantitative evaluation). 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.

[0090] 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.

[0091] 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.

[0092] In terms of timing isolation and security protection, two-level synchronization registers are deployed between the 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.

[0093] 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.

[0094] In some embodiments of the application, S103 can be implemented through S201-S203, as follows:

[0095] 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.

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

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

[0098] In some embodiments of the 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.

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

[0100] For example, when the RTL logic or data of the dynamic module is detected to be corrected, the hot update without interruption is realized by any of the following ways:

[0101] 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, and is loaded to the specified reconfiguration area of the FPGA through the debugging interface.

[0102] 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).

[0103] (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.

[0104] 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.

[0105] 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, return to the partial dynamic reconfiguration mode of step (1); if it is a data parameter error, return to the SRAM hot patch mode of step (2).

[0106] 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.

[0107] In some embodiments of the present application, the method further comprises:

[0108] If the error type is a logical error, the mobile EDA tool is automatically triggered for incremental compilation and differential bitstream loading to handle the logical error.

[0109] If the error type is a data parameter error, a script is called to regenerate configuration data to fix the data parameter error.

[0110] In the case of fixing the logical error or fixing the data parameter error, a key function regression test is automatically performed.

[0111] 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 mobile simulation tool (such as lightweight Verdi / VCS), and the parallel test framework driven by Makefile and the orthogonal experimental design (OED) method are used to realize more than 90% of the design boundary condition automatic regression test coverage. 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 scripts to regenerate configuration data to fix data errors, and automatically performs key function regression tests after updating.

[0112] The tool chain deep collaboration and closed-loop verification mechanism is 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).

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

[0114] 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 scripts to regenerate configuration data to fix data errors, and automatically performs key function regression tests after updating.

[0115] Efficient error location: By setting breakpoints in the Verdi waveform interface, single-stepping through critical modules, or using the Verilog system task $display to output error information, problems can be quickly located to specific modules and code lines, reducing error location time by about 30%-50%.

[0116] 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.

[0117] 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, and is based on the SoC design, FPGA technology, EDA tool, storage technology and other branches in the key digital technology patent classification system. Compared with the traditional method, it reduces the comprehensive time by 75% and the iteration of stream processing by 3-4 times, improves the verification efficiency and stream processing success rate, 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.

[0118] 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 field of mobile intelligent terminals and artificial intelligence in the Key Digital Technology Patent Classification System (2023), and constructs a complete software and hardware cooperative 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.

[0119] The hardware operating subsystem integrates key devices such as a low-power FPGA prototype verification development board, a Xilinx Vivado design suite, a Xilinx FPGA programmer, and the like, and strictly follows the hardware specifications of the mobile intelligent terminal chip technology branch in the classification system. Considering the stringent 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 the 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 routing) are sequentially completed, and finally a 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 the 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.

[0120] The software operating subsystem integrates a Cadence Verdi / VCS simulation suite, an ARM Keil MDK development environment, an ICP debugging interface module, and a wireless UART monitoring unit suitable for mobile intelligent terminals, and strictly corresponds to the software technical requirements of EDA tools and mobile intelligent terminal chip design in the classification system. Among them, the Verdi / VCS simulation suite carries out joint simulation verification of the RTL design function level of the mobile intelligent terminal SoC according to the machine learning and pattern recognition algorithms of "artificial intelligence general technology" in the classification system; the Keil MDK development environment realizes the cross-compilation of assembly language programs and C language test programs according to the programming specifications of logic chips in "mobile intelligent terminal chip design"; the ICP debugging interface module, as a bridge connecting the Keil development environment and the FPGA verification platform, follows the interface protocol standard in "packaging test" to complete the burning of Hex format executable files to the SRAM on the SoC; the wireless UART module collects and transmits system running state data in real time, and refers to the monitoring mechanism of "mobile internet security layer" to realize the monitoring and management of the whole life cycle of the mobile intelligent terminal high-end chip verification system, facilitating developers to remotely view the system status in a mobile scenario.

[0121] In order to more clearly show the application of the technical scheme of the present application in the verification of mobile intelligent terminal high-end chips, the specific implementation of the SOC chip prototype verification platform based on the dynamic reconfigurable architecture of FPGA is described as follows: Figures 2-6

[0122] I. FPGA RTL synthesis and module division system (PC end)

[0123] ​The system architecture of the FPGA-based high-end chip prototype verification platform for a mobile intelligent terminal includes an FPGA RTL synthesis device and an FPGA prototype verification platform, as shown in FIG. 1. Figure 2 The system takes a PC device loaded with the Xilinx Vivado design suite as the core, and establishes a physical connection with the FPGA verification board through a dedicated download line. The system has a built-in dynamic module intelligent division engine developed based on a Python script. The engine adopts a timing critical path analysis (TCPA) and a functional coupling quantitative evaluation algorithm model to realize accurate division of SoC design modules in view of the complex and heterogeneous characteristics of a high-end chip SoC for a mobile intelligent terminal.

[0124] Static module deployment (system-level basic functions): Modules that are crucial to the stability of the entire system, such as a clock management unit (MMCM / PLL), a high-speed serial interface (such as MIPI, PCIe), a power management module (PMU), and other high-coupling units, are fixedly arranged in the Bank0-3 area of the FPGA. This ensures the basic timing stability of the entire prototype system (such as a simulated Android environment) during operation.

[0125] Dynamic module configuration (application processor and accelerator): Modules that are frequently iterated, such as the state machine (FSM) of the application processor (CPU), the algorithm module (such as FFT) in the AI acceleration core (NPU) or image signal processor (ISP), and the configuration register group, are allocated to the reserved reconfigurable area (PRR) (physical area X0Y120 to X50Y180) of the FPGA to support dynamic logic updates without interrupting system operation.

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

[0127] It should be noted that, Figure 2Vivado is an FPGA software tool from Xilinx, which is used to compile the chip design code (RTL) into a program that can run on the FPGA (bitstream file), and can also modify a certain module separately to generate a small patch (differential bitstream) for direct update. Keil is an IDE integrated development environment software, which is used to write and compile software programs (C / assembly code) for testing chips, generate executable files (Hex), and also directly modify the data in the chip memory (such as parameter tuning). Vcs / Verdi is an EDA tool from Synopsys, which is used to simulate the operation of the chip on the computer, check the design for problems in advance, and analyze the error of the signal like looking at the waveform. Figure 1 Uatt 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 determine whether it is a hardware logic problem or a data problem.

[0128] II. Software verification and debugging system (PC side)

[0129] This system integrates Keil development environment, serial debugging tools, and Cadence Verdi / VCS joint simulation suite, interacts with the hardware prototype through the SGW emulator and UART-to-USB line, and focuses on the software and hardware co-verification of mobile SoC:

[0130] Code compilation: Use Keil to cross-compile the assembly test code and C language program of the underlying driving firmware (Firmware), and generate Intel Hex format files that adapt to the hardware verification requirements.

[0131] Joint simulation: In the Verdi / VCS environment, associate the C_INIT_FILE_NAME signal of the SRAM IP core generated by Vivado with the MIF file to build a software and hardware 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.

[0132] Data conversion: Use Perl scripts (path / scripts / hex2coe.pl) to convert Hex to COE format to meet the data initialization format requirements of FPGA internal BRAM / SRAM modules.

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

[0134] III. FPGA hardware verification platform

[0135] The platform takes Xilinx Artix-7 XC7A200T-2FBG484I FPGA as the core, simulates the hardware environment of mobile intelligent terminal SoC, and is configured as follows:

[0136] Storage system: integrated dual-bank SPI Flash (Micron N25Q128A) to store A / B dual configuration bitstreams of stable and development versions respectively, ensuring quick rollback of the system in case of update failure, which is crucial for long-running system-level verification.

[0137] Interface configuration: standard JTAG interface connects FPGA configuration pins (Bank0), supporting bitstream download and hardware-level debugging.

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

[0139] 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).

[0140] Four, module division rules and verification process

[0141] Dynamic threshold division strategy:

[0142] This strategy is optimized for RTL design of large mobile intelligent terminal high-end chips. As shown in Figure 3 , starting from the complete mobile intelligent terminal SoC RTL design, recursive modular division is adopted with an initial coupling threshold of 30%: the first division generates static module 1 (containing the entire mobile intelligent terminal SoC clock network, high-speed interface, and other infrastructure) and dynamic module 1, and static module 1 is fixed to FPGA1; the threshold of each subsequent level is dynamically calculated at 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 modules are deployed to FPGA2-FPGAn in turn, while the dynamic modules continue to be iteratively divided until the resource and timing termination conditions of the reconfigurable area are met.

[0143] Prototype verification workflow:

[0144] Hardware configuration: full compilation generates base.bit, and incremental compilation generates diff.bit during dynamic update, which is downloaded to the FPGA prototype via JTAG.

[0145] 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 by Perl script, and then Vivado script is used to adapt the test data to the memory initialization file of FPGA.

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

[0147] Dual-mode hot update mechanism:

[0148] This mechanism is the core advantage of the scheme, which can realize the "online surgical" repair of mobile intelligent terminal SoC prototype without restarting the entire verification system.

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

[0150] Logic error repair (online update algorithm / logic): when the UART returns error code 0xE1 (for example, NPU inference result error), trigger the logic error repair 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 reconfigurable technology, the fast logic update of NPU or ISP algorithm core can be completed within ≤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.

[0151] Data error repair (online parameter modification): when the UART returns error code 0xE2 (for example, some configuration parameter error in the memory), use the Memory window of Keil development environment to execute the mem_write -addr 0x2000FF00 -data 0x1234 command 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 mobile intelligent terminal SoC modules that require a large number of parameter configurations for debugging (such as display controllers or sensor hubs).

[0152] Closed-loop safety verification system:

[0153] To ensure the stability of the long verification process, the platform introduces a closed-loop security verification system:

[0154] 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 a logic update failure or deadlock due to other reasons, the watchdog will automatically trigger an A / B Bank switching instruction reset_config -bankB, causing the FPGA prototype to 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.

[0155] Software operation steps:

[0156] In the Keil MDK development environment, select the device model as the ARM Cortex-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.

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

[0158] Use the corresponding compiler to translate and build the assembly code and C language test program of the underlying driver, generating a hexadecimal hex file. This process belongs to the "firmware generation and compilation" link in the design process of high-end mobile intelligent terminal SoCs.

[0159] Copy the generated hex file to the Linux workstation.

[0160] Convert it to a coe file through a Perl script to adapt to the initialization format of the FPGA internal Block RAM. This meets the technical requirements of "data format adaptation" in the design process of mobile intelligent terminal SoCs.

[0161] Import the coe file into the Vivado software as the initialization data for specific IP cores in the mobile intelligent terminal SoC (such as the instruction SRAM of the NPU).

[0162] Generate the corresponding MIF file and two IP core simulation model.v files.

[0163] Copy the relevant files to the Linux system of the FPGA prototype verification platform and instantiate them in the RTL code of the mobile intelligent terminal SoC top-level design.

[0164] The C_INIT_FILE_NAME signal of the top-level file of the simulation model is associated to the MIF file address, and the "IP core integration and system modeling" is completed, and a hardware prototype containing software behavior is constructed.

[0165] The Makefile script is run under the Linux system, and the Verdi / VCS joint simulation of the entire mobile intelligent terminal SoC design is carried out.

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

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

[0168] In Keil, the software connection ICP debugging interface is connected with the simulated mobile intelligent terminal SoC program download interface on the FPGA verification board.

[0169] 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.

[0170] During the verification process, the UART real-time monitoring output is based on regular expression matching of abnormal characteristics:

[0171] 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, "logical hot update" is realized.

[0172] 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.

[0173] As shown in Figure 5 , this scheme is based on standardized design process and innovative hardware configuration strategy for mobile intelligent terminal SoC, and realizes efficient hardware prototype verification on FPGA platform. The specific implementation steps are as follows:

[0174] For the RTL design of the target mobile intelligent terminal SoC, FPGA architecture adaptation optimization is carried out.

[0175] The focus is to complete the migration and adaptation of the clock module (Clocking Wizard), reset logic (Processor System Reset), memory unit (such as DDR controller), and GPIO interface in the mobile intelligent terminal SoC.

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

[0177] Based on the physical resources of the FPGA, a static-dynamic partitioning strategy is adopted for the modular layout planning of the mobile intelligent terminal SoC, and precise layout is achieved through Vivado Tcl commands:

[0178] Static module solidification: using commands such as set_property PACKAGE_PIN AE12 [get_cells clk_wiz], the clock management, high-speed interface (such as MIPI D-PHY), and other key modules in the mobile intelligent terminal SoC are fixed at the specified physical location, ensuring the timing stability of the prototype system's basic functions.

[0179] Dynamic area reservation: through commands such as define_pblock PR_Region -rect {10 10 50 50}, a portion of the reconfigurable area (Partial Reconfiguration Region) is divided for modules such as NPU and ISP that require frequent algorithm iteration, providing hardware resource support for logic dynamic updating.

[0180] As shown in Figure 6 , a complete constraint file system is constructed for the mobile intelligent terminal SoC prototype, including timing constraints and pin physical constraints:

[0181] 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, and through optimizing the delay of the critical path, the accuracy of signal transmission timing is ensured.

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

[0183] Import the optimized mobile intelligent terminal SoC RTL code and constraint files into the Vivado design suite.

[0184] The logic synthesis and placement and routing processes are executed sequentially to generate a full bitstream file for initialization and a differential bitstream file for hot updates.

[0185] The bitstream is burned into the FPGA chip via the JTAG interface, completing the hardware prototype deployment of the mobile smart terminal SoC design.

[0186] Constructing a dual-bank redundant storage architecture enhances the security and fault tolerance of the mobile smart terminal SoC verification process:

[0187] Version management: BankA stores a stable baseline version bitstream (base.bit), and BankB stores the current development version to be verified (test.bit). Switching can be triggered via GPIO buttons (e.g., loading BankB when switches[0]=1'b1), facilitating quick switching and comparison between different functional versions.

[0188] State maintenance: Before performing dynamic updates, the state of critical registers (such as PMU configuration and interrupt controller state) inside the mobile smart terminal SoC is backed up to BRAM using the command `reg_save -file backup.reg`. If an anomaly occurs during verification and causes a system crash, the system context can be quickly restored using the command `reg_restore -file backup.reg`, forming a secure closed-loop management of the verification process.

[0189] Based on the above embodiments of the intelligent terminal SoC prototype verification method based on FPGA partial dynamic reconfiguration, this application also provides an intelligent terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration, such as... Figure 7 As shown, Figure 7 This application provides a schematic diagram of the structure of a smart terminal SoC prototype verification system based on FPGA partial dynamic reconfiguration. The system includes: an acquisition module 701, a generation module 702, a selection module 703, a determination module 704, and a verification module 705.

[0190] The acquisition module 701 is used to acquire predetermined dynamic modules and static modules; wherein, the dynamic modules and the static modules are obtained by adaptively allocating the hardware resources of the mobile smart terminal chip;

[0191] The generation module 702 is used to perform joint verification of the prototype based on the dynamic module and the static module, and generate a coverage report.

[0192] The selection module 703 is configured to select a dynamic module hot updating mode if the coverage report indicates that there is an error.

[0193] The determination module 704 is configured to determine an error type in the dynamic module hot updating mode, and perform error repair according to the error type to obtain a repaired file.

[0194] The verification module 705 is configured to perform joint simulation and system running verification based on the repaired file to obtain a verification result of the mobile intelligent terminal SoC prototype.

[0195] In some embodiments of the present application, the acquisition module 701 is further configured to acquire a plurality of functional modules of a register transfer level of the mobile intelligent terminal SoC to be verified before acquiring the pre-determined dynamic module and static module.

[0196] The determination module 704 is further configured to calculate a coupling degree corresponding to each of the plurality of functional modules, and determine each of the plurality of functional modules as the static module if the coupling degree of the each of the plurality of functional modules is greater than a preset coupling degree, or determine the each of the plurality of functional modules as the dynamic module if the coupling degree of the each of the plurality of functional modules is less than or equal to the preset coupling degree.

[0197] In some embodiments of the present application, the determination module 704 is further configured to determine, for each of the plurality of functional modules, a signal interaction number of the each of the plurality of functional modules with other functional modules, determine a total number of the plurality of functional modules, and calculate the coupling degree of the each of the plurality of functional modules based on the signal interaction number of the each of the plurality of functional modules with other functional modules and the total number of the plurality of functional modules to obtain the coupling degree corresponding to each of the plurality of functional modules.

[0198] In some embodiments of the present application, the static module is solidified in a bit stream of the FPGA, and includes a 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 it is synthesized for the first time; the dynamic module supports runtime updating, and includes a state machine jump logic of a processor core, an algorithm parameter of an AI accelerator or a register configuration table of a GPU.

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

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

[0201] In some embodiments of the present application, the verifying module 705 is further configured to automatically trigger an incremental compilation and a differential bitstream loading of a mobile terminal EDA tool to repair the logic error if the error type is the logic error; call a script to regenerate configuration data to repair the data parameter error if the error type is 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.

[0202] Based on the FPGA partial dynamic reconstruction-based intelligent terminal SoC prototype verification method of the above embodiments, an FPGA partial dynamic reconstruction-based intelligent terminal SoC prototype verification device is further provided in the embodiments of the present application, as shown in Figure 8 Figure 8 A structure diagram of the FPGA partial dynamic reconstruction-based intelligent terminal SoC prototype verification device provided in the embodiments of the present application is shown in the figure. The FPGA partial dynamic reconstruction-based intelligent terminal SoC prototype verification device 8 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 execute the FPGA partial dynamic reconstruction-based intelligent terminal SoC prototype verification method as described in the above embodiments.

[0203] ​In the embodiments of the present 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 used to implement the functions of the processor can also be other devices, and the embodiments of the present application are not limited in this regard.

[0204] The embodiments of the present application provide a computer readable storage medium storing a computer program, which is used to implement the FPGA partial dynamic reconfiguration based intelligent terminal SoC prototype verification method according to any one of the above embodiments when executed by a processor.

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

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

[0207] If the integrated unit is implemented in the form of a software function module and is not sold or used as an independent product, it can be stored in a computer readable storage medium based on such understanding. The technical solutions of the embodiments can essentially or contribute to the prior art or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the embodiments. The aforementioned storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0208] 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 refer to 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 order of execution, and 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, this paper will not be repeated here.

[0209] 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.

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

[0211] Those skilled in the art can understand that all or part of the steps of the foregoing method embodiments can be completed by relevant hardware of program instructions, and the foregoing program can be stored in a computer readable storage medium. When the program is executed, the program executes the steps of the foregoing method embodiments. The foregoing storage medium includes a mobile storage device, a read only memory (ROM), a magnetic disc or an optical disc, and various media that can store program codes.

[0212] 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.

[0213] 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.

[0214] 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.

[0215] The foregoing is only a manner of implementing the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited to this. 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 an 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; wherein, before acquiring the predetermined dynamic module and the 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 the coupling degree of each of the plurality of functional modules; if the coupling degree of each of the plurality of functional modules is greater than a preset coupling degree, determining each of the plurality of functional modules as the static module; if the coupling degree of each of the plurality of functional modules is less than or equal to the preset coupling degree, determining each of the plurality of functional modules as the dynamic module; wherein the static module is fixed in the bit stream of the FPGA, and includes the clock network, the high-speed interface or the fixed logic of the 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 includes the state machine jump logic of the processor core, the algorithm parameter of the AI accelerator or the register configuration table of the GPU.

2. The method of claim 1, wherein, The calculation of the coupling degree of each of the plurality of functional modules comprises: for each of the plurality of functional modules, determining the number of signal interactions between the functional module and other functional modules; determining the total number of modules of the plurality of functional modules; based on the number of signal interactions between each of the plurality of functional modules and other functional modules, and the total number of modules of the plurality of functional modules, calculating the coupling degree of each of the plurality of functional modules to obtain the coupling degree of each of the plurality of functional modules.

3. The method of claim 1, wherein, In the dynamic module hot update mode, determining the error type; and according to the error type, performing error repair 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 method corresponding to the error type; according to the error repair method corresponding to the error type, repairing the error type to obtain the repaired file.

4. The method of claim 3, wherein, If the error type is the logic error, determining that the error repair method corresponding to the logic error is a partial dynamic reconstruction 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 a partial dynamic reconfiguration mode and an SRAM hot patch mode.

5. 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 a case where the repair of the logic error is completed or the data parameter error is repaired, automatically performing a critical function regression test.

6. 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. The acquisition module is configured to acquire a predetermined dynamic module and a static module. The generation module is configured to generate a coverage report 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. The acquisition module is further configured to acquire a plurality of functional modules of a register transfer level of a mobile intelligent terminal SoC to be verified, calculate a coupling degree of each functional module of the plurality of functional modules, and determine each functional module as the static module if the coupling degree of each functional module is greater than a preset coupling degree. 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.

7. An intelligent terminal SoC prototype verification device based on FPGA partial dynamic reconfiguration, characterized in that, The static module is fixed in a bitstream of the FPGA and contains a clock network, a high-speed interface, or fixed logic of a hardware accelerator of the mobile intelligent terminal SoC. The static module is merged into a single bitstream and needs full compilation only at the first time of synthesis. The dynamic module supports runtime update and contains state machine jump logic of a processor core, algorithm parameters of an AI accelerator, or a register configuration table of a GPU. The system comprises a processor and a memory.

8. A computer-readable storage medium, characterized in that, 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 in any one of claims 1 to 5. Executable instructions are stored to cause the processor to implement the method in any one of claims 1 to 5 when executed.

Images