FPGA hardware platform management method

Abstract

The invention provides an FPGA (Field Programmable Gate Array) hardware platform management method, which comprises the following steps of: outputting management configuration files corresponding to a plurality of FPGA hardware platforms connected with an FPGA server in response to an FPGA hardware platform access request; in response to a selection operation on the management configuration file, executing the selected management configuration file, and collecting hardware running state information of the first FPGA hardware platform; the first FPGA hardware platform refers to an FPGA hardware platform corresponding to the selected management configuration file, and the hardware running state information is analyzed to output the hardware running state of the first FPGA hardware platform; the hardware running state comprises running states of different FPGA devices in the first FPGA hardware platform.

Description

Technical Field

[0001] This application mainly relates to the field of chip design, and more specifically to a method for managing an FPGA hardware platform. Background Art

[0002] FPGA (Field Programmable Gate Array) prototype verification is a method of using an FPGA hardware platform to verify the functions and performance of an integrated circuit (IC) or a system-on-chip (SoC) design. As an important part of the chip design process, it is usually used to discover and fix errors in the chip design to ensure the correctness of the chip design's logic function and timing.

[0003] However, in the actual application of FPGA prototype verification, it often cannot accommodate large-scale designs due to resource limitations. If a large number of FPGA hardware platforms are used, manual online communication is usually required, which is time-consuming and laborious, and it is very easy to cause misoperations due to communication deviations, thus bringing the risk of firmware loss to the FPGA hardware platform. Summary of the Invention

[0004] In view of the above problems, this application provides the following solutions:

[0005] In a first aspect of this application, a method for managing an FPGA hardware platform is provided, and the method includes:

[0006] In response to an FPGA hardware platform access request, output management configuration files corresponding to multiple FPGA hardware platforms connected to an FPGA server;

[0007] In response to a selection operation on the management configuration file, execute the selected management configuration file, and collect hardware operation status information of a first FPGA hardware platform; the first FPGA hardware platform refers to the FPGA hardware platform corresponding to the selected management configuration file;

[0008] Analyze the hardware operation status information, and output the hardware operation status of the first FPGA hardware platform; the hardware operation status includes the operation status of different FPGA devices in the first FPGA hardware platform.

[0009] In a possible implementation, the collecting of the hardware operation status information of the first FPGA hardware platform includes at least one of the following:

[0010] Collect address change information of the currently executed instruction in the first FPGA hardware platform; the address change information reflects the current usage status of the first FPGA hardware platform;

[0011] Collect data transmission information between different functional modules in the first FPGA hardware platform; the data transmission information reflects the usage frequency of the corresponding functional module.

[0012] Collect access information of each functional module in the first FPGA hardware platform; the access information reflects the operation behaviors existing in the current first FPGA hardware platform.

[0013] Collect status information of each subsystem in the first FPGA hardware platform; the status information reflects one or more of the operation mode, resource utilization rate, communication status, and exception information of the corresponding subsystem.

[0014] In a possible implementation, the analyzing the hardware operation status information to determine the hardware operation status of the first FPGA hardware platform includes:

[0015] Determine multiple pre-configured hardware operation status relation tables for the first FPGA hardware platform; one hardware operation status relation table includes the hardware operation statuses corresponding to different hardware operation status information in the same type of hardware operation status information.

[0016] Query the corresponding hardware operation status relation table according to at least one piece of the collected hardware operation status information, and output the hardware operation status of the first FPGA hardware platform after determination.

[0017] In a possible implementation, the collecting the address change information of the currently executed instruction in the first FPGA hardware platform includes:

[0018] Monitor the pointer jumps of the processor in the first FPGA hardware platform.

[0019] The collecting the data transmission information between different functional modules in the first FPGA hardware platform includes:

[0020] Collect the bus interface data of the first FPGA hardware platform.

[0021] The collecting the access information of each functional module in the first FPGA hardware platform includes:

[0022] Monitor the address bit changes of each register accessed in the first FPGA hardware platform.

[0023] In a possible implementation, the method further includes:

[0024] Store the collected hardware operation status information in a log storage manner.

[0025] Analyzing the hardware operation status information and outputting the hardware operation status of the first FPGA hardware platform, including:

[0026] Responding to a query request for the second FPGA hardware platform, determining the target status type of the second FPGA hardware platform for which the query is requested;

[0027] According to the hardware operation status relationship table corresponding to the second FPGA hardware platform and the target status type, selecting at least one piece of hardware operation status information corresponding to the target status type from the stored hardware operation status information corresponding to the second FPGA hardware platform;

[0028] Analyzing the at least one piece of hardware operation status information and outputting the hardware operation status of the second FPGA hardware platform.

[0029] In a possible implementation, the outputting the hardware operation status of the first FPGA hardware platform includes:

[0030] Sending the analyzed hardware operation status of the first FPGA hardware platform to the system server to realize the visual display of the hardware operation status.

[0031] In a possible implementation, the sending the analyzed hardware operation status of the first FPGA hardware platform to the system server includes:

[0032] According to the Secure Shell protocol, compiling the hardware operation status of the first FPGA hardware platform using a preset compilation language to obtain a data transmission script;

[0033] Running the data transmission script and sending the hardware operation status of the first FPGA hardware platform to the system server.

[0034] In a possible implementation, the method further includes:

[0035] Responding to a verification request for a to-be-verified function, determining multiple candidate FPGA hardware platforms that support the to-be-verified function;

[0036] According to the respective hardware operation statuses of the current multiple candidate FPGA hardware platforms, selecting a target FPGA hardware platform for the to-be-verified function from the multiple candidate FPGA hardware platforms;

[0037] Controlling the target FPGA hardware platform to run the to-be-verified function.

[0038] In a possible implementation, the method further includes any one of the following:

[0039] In response to a remote control instruction for any one of the FPGA hardware platforms, according to the hardware operating state of the FPGA hardware platform, control the FPGA hardware platform to perform corresponding operations;

[0040] In response to a locking request for any one of the FPGA hardware platforms, lock the hardware resources of the FPGA hardware platform to reject the usage request for the FPGA hardware platform;

[0041] In response to an FPGA device interconnection request for multiple FPGA hardware platforms, control the data interaction between the multiple FPGA devices requesting interconnection.

[0042] In a possible implementation, the management configuration file includes a monitoring logic for the hardware operating state of the corresponding FPGA hardware platform, and configuration information for configuring the underlying environment of the corresponding FPGA hardware platform;

[0043] The monitoring logic is pre-embedded into the corresponding FPGA hardware platform to collect the hardware operating state information of the corresponding FPGA hardware platform according to the monitoring logic.

[0044] The second aspect of this application also provides an FPGA hardware platform management device, including:

[0045] A first output module, configured to output the management configuration files corresponding to each of the multiple FPGA hardware platforms connected to the FPGA server in response to an FPGA hardware platform access request;

[0046] A collection module, configured to execute the selected management configuration file in response to a selection operation on the management configuration file, and collect the hardware operating state information of the first FPGA hardware platform; the first FPGA hardware platform refers to the FPGA hardware platform corresponding to the selected management configuration file;

[0047] A second output module, configured to analyze the hardware operating state information and output the hardware operating state of the first FPGA hardware platform; the hardware operating state includes the operating states of different FPGA devices in the first FPGA hardware platform.

[0048] The third aspect of this application also provides an FPGA server, including: a plurality of communication components, at least one memory, and at least one processor, where:

[0049] The plurality of communication components are respectively configured to implement the communication between the FPGA server and at least one FPGA hardware platform and the system server;

[0050] The memory is used to store a plurality of computer instructions;

[0051] The processor is used to load and execute the computer instructions to implement the following steps:

[0052] In response to an FPGA hardware platform access request, output management configuration files corresponding to respective multiple FPGA hardware platforms connected to the FPGA server;

[0053] In response to a selection operation on the management configuration file, execute the selected management configuration file and collect hardware operation status information of a first FPGA hardware platform; the first FPGA hardware platform refers to the FPGA hardware platform corresponding to the selected management configuration file;

[0054] Analyze the hardware operation status information and output the hardware operation status of the first FPGA hardware platform; the hardware operation status includes the operation statuses of different FPGA devices in the first FPGA hardware platform. Description of the Drawings

[0055] In combination with the drawings and with reference to the following specific embodiments, the above and other features, advantages and aspects of the various embodiments of the present disclosure will become more obvious. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic and the original elements and elements are not necessarily drawn to scale.

[0056] Figure 1 It is a schematic flowchart of the first optional embodiment of an FPGA hardware platform management method proposed by the present application;

[0057] Figure 2 It is a schematic flowchart of the second optional embodiment of an FPGA hardware platform management method proposed by the present application;

[0058] Figure 3 It is a schematic diagram of the acquisition process of hardware operation status information applicable to the FPGA hardware platform management method proposed by the present application;

[0059] Figure 4 It is a schematic flowchart of the third optional embodiment of an FPGA hardware platform management method proposed by the present application;

[0060] Figure 5 It is a schematic diagram of the system architecture applicable to the FPGA hardware platform management method proposed by the present application;

[0061] Figure 6 It is a schematic diagram of the acquisition scenario of hardware operation status information applicable to the FPGA hardware platform management method proposed by the present application;

[0062] Figure 7Schematic flowchart of the fourth optional embodiment of the FPGA hardware platform management method proposed in this application;

[0063] Figure 8 Schematic architecture diagram of the system server applicable to the FPGA hardware platform management method proposed in this application;

[0064] Figure 9 Schematic flowchart of the fifth optional embodiment of the FPGA hardware platform management method proposed in this application;

[0065] Figure 10 Schematic structural diagram of the FPGA hardware platform management device proposed in the embodiment of this application;

[0066] Figure 11 Schematic hardware structure diagram of an FPGA server proposed in this application. Detailed implementation manners

[0067] The embodiments of this application will be described below with reference to the accompanying drawings in the embodiments of this application. The terms used in the implementation manners part of this application are only used to explain the specific embodiments of this application, rather than intended to limit this application. The embodiments of this application will be described below with reference to the accompanying drawings. As known to those of ordinary skill in the art, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0068] The terms "first", "second", etc. in the context of the specification of this application and the above accompanying drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, which is only a way of distinguishing when describing objects with the same attributes in the embodiments of this application. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device including a series of units does not necessarily have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices.

[0069] To solve the above problems, the embodiments of this application provide an FPGA (Field Programmable Gate Array) hardware platform management method. The FPGA hardware platform management method of the embodiments of this application will be introduced in detail below with reference to the accompanying drawings.

[0070] Refer to Figure 1, which is a schematic flowchart of an optional first embodiment of a method for managing an FPGA hardware platform proposed in this application. This method can be applied to an FPGA server, which can be connected to multiple FPGA hardware platforms to achieve intelligent management of each FPGA hardware platform and the FPGA devices it contains. As Figure 1 shown, the FPGA hardware platform management method proposed in this embodiment may include but is not limited to the following steps:

[0071] Step S11, in response to an FPGA hardware platform access request, output management configuration files corresponding to each of the multiple FPGA hardware platforms connected to the FPGA server;

[0072] In the embodiments of this application, an FPGA hardware platform can be a complete hardware system built based on FPGA devices, including peripheral circuits, interfaces, storage, power management, and various FPGA devices (such as various FPGA chips, used to execute hardware logic designs and provide capabilities such as parallel computing and high-speed interfaces), etc. Each FPGA hardware platform can be integrated into the FPGA server environment to form remotely accessible computing resources. Among them, if the FPGA server is a local server, FPGA acceleration cards can be inserted into the chassis. If the FPGA server is a cloud server, FPGA resources can be shared through virtualization technology. This application does not limit the composition structure of each FPGA hardware platform and its connection method to the FPGA server, and can be dynamically configured / adjusted according to actual needs. The implementation process will not be elaborated in this application.

[0073] It can be seen that the FPGA devices in this application belong to chip-level devices, relying on the FPGA hardware platform for power supply and interfaces. The FPGA hardware platform belongs to the board-level, relying on the FPGA server to provide control software, remote access, real-time monitoring, etc., and can be used to achieve prototype verification and hardware simulation, etc. The FPGA server relies on the FPGA hardware platform as a computing node, and can be used to achieve large-scale verification and real-time monitoring of the verification process to reasonably allocate the use of FPGA hardware. Especially during the peak usage period, resources can be reasonably allocated according to the monitoring results, improving the device usage efficiency and avoiding long waiting times for users to verify.

[0074] Based on the above analysis, in scenarios where it is necessary to monitor or query the hardware operating status of an FPGA hardware platform, or the usage of a certain FPGA device, etc., a terminal device can be used to connect to the FPGA server and initiate an FPGA hardware platform access request, so that the FPGA server responds to this access request and outputs the management configuration files corresponding to each FPGA hardware platform currently connected to the FPGA server for users to flexibly select.

[0075] Optionally, it is possible to log in to the FPGA hardware platform management system provided by the FPGA server to output the FPGA hardware platform management interface, and display the management configuration files corresponding to each FPGA hardware platform in this FPGA hardware platform management interface. The management configuration file is used to indicate how to implement the monitoring of the hardware operating state of the corresponding FPGA hardware platform. For example, it includes the monitoring logic for implementing this monitoring function, and includes configuration data for the underlying environment of the corresponding FPGA hardware platform, etc. It can be pre-constructed by the FPGA server developer for different FPGA hardware platforms before executing the access request and sent to the FPGA server. This application places no restrictions on the content of the management configuration file and how it is written into the FPGA server.

[0076] Among them, it should be understood that for each FPGA hardware platform with different component structures or different types of structural compositions, the supported functions may be different, and even the execution processes for implementing the same function may be different. In order to implement the monitoring of different versions of FPGA hardware platforms, it is possible to pre-configure the management configuration files corresponding to each FPGA hardware platform. For example, the Bit file generated in the corresponding FPGA underlying environment using an FPGA development tool (such as Xilinx Vivado or ISE, etc.) is used to map the designed logic (such as the monitoring logic, complete configuration information of FPGA internal logic units, wiring resources, and I / O settings, etc.) to the FPGA server and its integrated FPGA hardware to support the implementation of the method provided by this application and the verification function of the FPGA hardware platform, etc. This application places no restrictions on the content of the management configuration file and its generation method.

[0077] Step S12, in response to the selection operation of the management configuration file, execute the selected management configuration file to collect the hardware operating state information of the first FPGA hardware platform;

[0078] In practical applications, users can, according to the actual management requirements for the FPGA hardware platform, select the management configuration files corresponding to one or more FPGA hardware platforms to be managed (in order to distinguish the unselected FPGA hardware platforms, the selected FPGA hardware platforms can be recorded as the first FPGA hardware platform) from the output management configuration files corresponding to each FPGA hardware platform. In response to this selection operation, the selected management configuration files can be executed, and according to the monitoring logic they contain, the real-time monitoring of the hardware operating state of the corresponding first FPGA hardware platform can be realized, and the corresponding hardware operating state can be automatically collected.

[0079] In a possible implementation, the hardware operating states of the first FPGA hardware platform (i.e., the FPGA hardware platform corresponding to the selected configuration file) that this application needs to monitor may include, but are not limited to: power states (such as voltage and current, etc.), temperature states (such as chip temperature and ambient temperature, etc.), configuration states (such as configuration completion signal, configuration exception signal, etc.), clock states (such as clock frequency and skew, etc.), I / O states (such as levels of I / O pins, data transmission direction, etc.), communication states (such as internal communication signals, external communication interface signals, etc.), and critical signal states (such as register values, state machine states, etc.), etc., to optimize the FPGA design, troubleshoot hardware faults, and ensure the stable operation of the system.

[0080] Optionally, this application can also collect in real time the hardware operating state information of the first FPGA hardware platform in several aspects, such as physical environments like temperature and power supply stability; logical resources and signal integrity like resource utilization rate and signal quality; communication and interface health states like protocol layer exceptions and link stability; real-time power consumption; debugging and predictive maintenance like soft error protection and long-term reliability, etc., to achieve reasonable management of the corresponding first FPGA hardware platform.

[0081] In addition, this application can also collect in real time one or more variables of one or more hardware operating states that reflect the usage state, operation behavior, usage frequency of each functional module it contains, and the states of each subsystem, etc., of the first FPGA hardware platform. The content of the hardware operating state information that this application needs to collect for the first FPGA hardware platform is not limited and can be determined according to the pre-configured monitoring logic. It should be noted that for different first FPGA hardware platforms, the types of hardware operating state information to be collected can be the same or different, which can be determined according to whether the corresponding monitoring logics are consistent.

[0082] Step S13, analyze the hardware operating state information and output the hardware operating state of the first FPGA hardware platform; this hardware operating state includes the operating states of different FPGA devices in the first FPGA hardware platform.

[0083] Following the above description of the hardware operating state information, the FPGA server can analyze one or more pieces of hardware operating state information that meet the requirements according to the actual monitoring / query needs, quickly and accurately determine the hardware operating state of the corresponding first FPGA hardware platform, without the need to communicate with the verification personnel using each FPGA device in the first FPGA hardware platform manually, improving the acquisition efficiency and accuracy of the hardware operating state of the FPGA hardware platform.

[0084] After analyzing one or more hardware operating states of each first FPGA hardware platform determined, visual display can be performed on them, so that the user who initiates the FPGA hardware platform management request can intuitively understand the actual usage of the first FPGA hardware platform, as well as the actual usage of each FPGA device in the first FPGA hardware platform, to assist the user in selecting the FPGA hardware platform / device that can currently provide the required services (such as design verification services, etc.) for access, and avoid accessing the first FPGA hardware platform / device with a relatively high current usage rate, resulting in insufficient computing resources, and having to wait in line until the computing resources of the first FPGA hardware platform / device are released before being able to continue accessing, which affects the service efficiency and the user experience.

[0085] It can be seen that in the scenario where a large number of FPGA hardware platforms connected to the FPGA server are in extensive use, the method proposed in this application can be used to achieve real-time monitoring of the hardware operating states of each FPGA hardware platform, quickly and accurately obtain the usage conditions of each FPGA hardware platform, without the need for manual online communication, saving time and effort and having high efficiency, reducing the risk brought by misoperations, reducing the influence among testers, ensuring that the hardware operating states output by this application are reliable and accurate, and being able to notify the user of the information on the use of FPGA device resources in real time, avoiding the hardware usage risks brought by misoperating the platform, such as firmware damage, etc.

[0086] Refer to Figure 2 , which is a schematic flowchart of the second optional embodiment of a method for managing an FPGA hardware platform proposed in this application. This embodiment can describe an optional refined implementation method for how to monitor the hardware operating state of the FPGA hardware platform in the above-mentioned FPGA hardware platform management method. As Figure 2 shown, this implementation method can include but is not limited to the following steps:

[0087] Step S21, collect the address change information of the currently executing instruction in the first FPGA hardware platform; the address change information reflects the current usage state of the first FPGA hardware platform;

[0088] In the case where this application embodiment proposes to monitor the hardware operating state of the FPGA hardware platform, in order to understand the usage state of the first FPGA hardware platform, variables that can reflect the usage state in the first FPGA hardware platform can be collected in real time, such as the change in the instruction stream of the currently executing program in the first FPGA hardware platform, that is, the address change information of the currently executing instruction in the first FPGA hardware platform. As Figure 3As shown, it can monitor the pointer jump of the processor in the first FPGA hardware platform (such as the CPU pointer jump). It can be used to analyze and determine the correctness of the corresponding program execution flow. For example, monitoring whether the CPU pointer accidentally jumps to an illegal address (such as an uninitialized memory area or a non-code segment), which may indicate software bugs (such as null pointer dereference) or hardware failures (such as bus errors), etc., to achieve the detection of abnormal jumps in the program execution flow. It can also track the jump paths of branch instructions (if / else, loops) in an FPGA that supports CPU cores (such as the soft-core MicroBlaze, hard-core ARM Cortex), and verify whether the prediction logic is consistent with the expectation, etc.

[0089] Among them, the acquisition of the CPU pointer jump can be achieved through a performance monitoring timer (a dedicated register for monitoring hardware events, used to provide detailed information about program execution), or through a debugger or other hardware-assisted debugging tools (which can directly monitor the running state of the CPU through a hardware interface), or performance analysis tools, or hardware / software performance monitoring units, or other real-time monitoring tools, etc. Of course, this application can also be implemented by inserting custom monitoring code, that is, directly monitoring the CPU pointer jump by inserting monitoring logic into the code.

[0090] In a possible implementation, for the address change information of the currently executed instruction collected in step S21, it can also be used to achieve real-time performance analysis. For example, by counting the residence time of the CPU pointer in a specific code segment, locate performance bottlenecks (such as high-latency functions or frequently called loops); by recording the number of instruction cycles from the interruption trigger to the PC jumping to the interrupt service routine (ISR), evaluate whether the real-time performance meets the standard to determine the interrupt response latency. Optionally, it can also implement malicious code injection (such as detecting whether the CPU pointer jumps to an unexpected address (such as the shellcode security code area after a buffer overflow attack)) and control flow integrity (such as preventing control flow hijacking behaviors such as ROP (Return-Oriented Programming) attacks (a sophisticated memory attack) through a whitelist of legitimate jump addresses), etc., all related to abnormal behavior detection.

[0091] In addition, the address change information of the currently executed instruction collected in step S21 can also be used to implement hardware / software co-debugging, such as hardware accelerator interaction (e.g., when the CPU interacts with the FPGA hardware accelerator through memory-mapped IO (MMIO), monitoring the jump of the CPU pointer in the driver code to verify whether the configuration / data transfer process is correct) and exception handling processes (e.g., tracking the jump path of the CPU after an exception occurs (such as page fault or illegal instruction, etc.) to confirm whether the handler is triggered correctly, etc.). It can also be used to analyze multi-core synchronization problems. For example, in a multi-core FPGA system (such as the ARM dual-core of Zynq), monitoring the jump timing of the CPU pointers of each core to detect situations such as deadlocks or data races caused by shared resource conflicts, and taking corresponding measures in a timely manner to reduce the risks brought by misoperations.

[0092] It should be noted that regarding the implementation method of step S21, its reflected usage status and analysis process, including but not limited to the several contents listed above, the present application can be determined in advance according to the actual situation, and record the specific address change information corresponding to different usage statuses. So that in actual applications, directly based on the actually collected address change information, read the usage status content corresponding to this address change information, without having to spend time analyzing and determining online, which improves the management efficiency. It should be understood that if the currently collected address change information is not recorded in advance, it can also be analyzed according to the method described above to determine the usage status of the first FPGA hardware platform at present.

[0093] Step S22, collect the data transfer information between different functional modules in the first FPGA hardware platform; this data transfer information reflects the usage frequency of the corresponding functional module;

[0094] In order to more accurately determine the usage of the FPGA hardware platform and its devices, the present application can also analyze the usage frequency of different functional modules in the first FPGA hardware platform, thereby determining the hardware resource usage of the first FPGA hardware platform, combined with the address change information of the currently executed instruction collected in step S21, to more accurately determine the actual usage of the first FPGA hardware platform, so as to assist in realizing the reasonable management of the FPGA hardware platform.

[0095] In practical applications, since the data transmission between different functional modules usually depends on the communication bus of the first FPGA hardware platform, that is, different functional modules are connected to the communication bus, so that the data output by the functional module is transmitted to other functional modules through this communication bus. It can be seen that the bus interface data can reflect the data interaction, control signal status, and overall operation of the functional modules inside the first FPGA hardware platform, such as which functional module is accessed and which functional module it communicates with for data, etc., so as to count the usage frequency of the corresponding functional module within a specified time, thereby indicating the resource utilization rate or other performance indicators of the functional module. Therefore, as Figure 3 shown, the implementation method of the above step S22 may include collecting the bus interface data of the first FPGA hardware platform.

[0096] In the embodiments of the present application, the above bus interface data may be AXI (Advanced eXtensible Interface, a bus protocol) bus interface data, or other types of bus interface data, which can be determined according to the bus protocol type configured by the corresponding first FPGA hardware platform. The following examples only take the AXI bus as an example for illustration, and for other types of buses, it can be determined according to their protocol content. The bus interface data collected in real time by the present application may include data signals, address signals, control signals, transmission status, burst transmission information, and system synchronization signals on the bus, etc., which can be based on the data transmission functions supported by the corresponding bus and the communication configured by the corresponding first FPGA hardware platform.

[0097] Among them, the data signal represents the data content actually transmitted, such as instructions, parameters (such as configuration parameters or status information), user data (such as image / audio data, sensor acquisition data, etc.), memory read / write data, etc. The address signal represents the target address or source address of the data transmission, such as the specific location of the read / write operation in the memory, the address of the specified peripheral register, the interface address of the specified functional module, etc.

[0098] The above control signal may be a read / write control signal, used to represent different states, such as read / write enable, data valid, ready, etc. Taking the AXI bus interface data as an example for illustration, the collected control signals may include: ARVALID of the AXI bus, indicating that the read address is valid and requesting a read operation; AWVALID of the AXI bus, indicating that the write address is valid and requesting a write operation; WVALID or RVALID of the AXI bus, indicating that the data signal is valid; WREADY or RREADY of the AXI bus, indicating that the receiving party is ready to receive data.

[0099] Similarly, the above response signals may include: the write response signal BRESP of the AXI bus to indicate the completion status of a write operation; the read response signal RRESP of the AXI bus to indicate the completion status of a read operation. The transmission status may include the status of the transmission completion signal and the transmission error signal, such as BVALID (write completion) and RVALID (read completion) of the AXI bus, indicating that a transmission operation has been completed; the error code in BRESP or RRESP of the AXI bus, indicating whether an error occurred during the transmission (such as address error, access permission error, etc.).

[0100] The above burst transfer information may include burst length (the number of data units included in a single burst transfer) / type (such as fixed, incrementing, or wrapping) / size (the size of each burst transfer unit), etc. The system synchronization signals may include a clock signal for synchronizing data transfer to ensure that all signals are within the same clock domain, and a reset signal for initializing the bus state to ensure that the system is in a known state at startup, etc.

[0101] Combined with the relevant descriptions of various bus interface data in the above embodiments, the collection of the corresponding data / status can be realized according to the strings / identifiers / field contents of different data / status defined by the bus protocol, such as the above, so as to analyze and determine the correctness of data transfer, the performance of the corresponding first FPGA hardware platform (such as bandwidth utilization, latency, etc.), and the health status, etc. Subsequently, the management of the corresponding first FPGA hardware platform can be realized based on these analysis contents.

[0102] Step S23, collect the access information of each functional module in the first FPGA hardware platform; this access information reflects the operation behaviors existing in the current first FPGA hardware platform.

[0103] In order to more directly and accurately determine the actual access situation of the functional modules inside the first FPGA hardware platform, such as determining what access is performed on what field of which functional module to achieve what, etc., this application can also directly collect the access information of each functional module and analyze to determine the operation behaviors that generate this access information.

[0104] In a possible implementation, in order to determine the communication status, data flow, and access situation of hardware resources among the functional modules inside the first FPGA hardware platform, such as Figure 3As shown, this application can monitor the changes in the address bits of each register accessed in the first FPGA hardware platform to analyze and determine. Among them, the high-order address bits of the register can be used to distinguish different hardware modules, and the low-order address bits can be used to access different registers or different fields within the module. In this way, through the monitored changes in the address bits, the communication between different functional modules, the access to hardware resources, the status of control signals, interrupt handling, DMA (Direct Memory Access) operations, bus transactions, error detection, performance analysis, debugging and verification, and the overall status of the system can be analyzed and determined.

[0105] Among them, the change in the address bits of the register usually indicates that one module is accessing the register of another module. For example, a processor module may access the register of a peripheral module through the address bus to read status information or write control commands, and it can also be further determined whether there is an address conflict. This change in the address bits may also be accompanied by data transmission. For example, when the address signal jumps, the data signal may change simultaneously, indicating that data is being written or read. If the register address is mapped to other spaces, such as the memory space or peripherals, etc., the change in this address bit can indicate the access to the mapped space. In interrupt handling, the change in the address bits can indicate that the interrupt status register is being accessed to determine which interrupts are triggered, and the change in the address bits may also indicate that the interrupt enable register is being accessed to enable or disable certain interrupts.

[0106] The DMA operations that the change in the address bits of the register may represent can include access to the DMA control / status register. The bus transactions that it may represent can include bus master / slave device access. For example, a certain bus master device (such as a processor or a DMA controller) is accessing a bus slave device (such as memory or peripherals, etc.), and the bus slave device is responding to the access request of the master device, etc. If the change in the address bits of the register exceeds the expected address range, it may indicate an illegal address access; by analyzing the access frequency of the hardware module through the change frequency of the register address bits, and by analyzing the access latency of the functional module through the time interval between the change of the address signal and the change of the data signal. This application can also quickly locate problems in the hardware design or verify whether the functions of the functional design meet the expectations through the change in the address bits. The collected changes in the address bits can represent the status of the system startup / operation / failure, etc.

[0107] Step S24, collect the status information of each subsystem in the first FPGA hardware platform; this status information reflects one or more of the operating mode, resource utilization rate, communication status, and exception information of the corresponding subsystem.

[0108] In practical applications, the functions of different subsystems of the FPGA hardware platform often vary, and the states of each subsystem can also reflect the operation of the entire system of the FPGA hardware platform. Therefore, the present application can also collect the state information of each subsystem to accurately determine which subsystem the program currently executed by the first FPGA hardware platform accesses, promptly detect abnormal subsystems, and take measures on them in a timely manner.

[0109] Among them, the state information of the processing system subsystem in the first FPGA hardware platform may include but is not limited to: the operating frequency state, utilization rate, currently running processes or threads, etc. of the CPU; the memory usage rate, remaining space, and read / write speed, etc. of the memory; the communication states of peripherals such as UART (Universal Asynchronous Receiver / Transmitter), I2C (Inter-Integrated Circuit), and SPI (Serial Peripheral Interface) to determine whether there is data transmission or an error; the interrupt state, system temperature, clock state, etc.

[0110] The state information of the programmable logic subsystem in the first FPGA hardware platform may include but is not limited to: the logic resource utilization rate (i.e., the usage of module resources), hardware exception detection information, data transmission status (such as the data transmission situation with external memories or peripherals), and clock states such as the frequency, jitter, and stability of clock signals. The state information of the storage subsystem in the first FPGA hardware platform may include: the memory utilization rate, bandwidth utilization rate, error detection such as memory access address / data errors, and data transmission status such as the data transmission situation between the memory and the processing engine.

[0111] The state information of the I / O subsystem in the first FPGA hardware platform may include the communication states, timing, and delay situations of various I / O interfaces, error detection of communication interfaces, etc. The state information of the instruction processing subsystem may include: states such as the length and processing speed of the instruction queue, the current state and operation of the main state machine, and the instruction parsing state; the state information of the hardware acceleration subsystem may include: the execution situation of hardware acceleration tasks, resource utilization rate, and operation errors, etc.

[0112] Thus, it can be seen that the present application can determine the type of state information that needs to be detected according to the functions implemented by each subsystem in the first FPGA hardware platform to achieve a finer-grained operation of the corresponding subsystem, including but not limited to the types of each subsystem and the content of their state information listed above. The embodiments of the present application directly collect the state information of each subsystem and combine it with other aspects of information monitored on the first FPGA hardware platform, such as Figure 3as shown (which shows an optional example of collecting four types of status information, without limiting the transmission method of each status information, and the monitored hardware operating status information is not limited to Figure 3 the four types of status information shown), so as to accurately and comprehensively understand the usage of the first FPGA hardware platform through analysis, automatically and reasonably allocate the hardware resources of each first FPGA hardware platform, reduce the waiting time of user requests, and avoid the hardware usage risks brought by misoperating the platform.

[0113] Referring to Figure 4 , it is a schematic flowchart of an optional Embodiment 3 of a method for managing an FPGA hardware platform proposed in this application. As Figure 4 shown, the method for managing an FPGA hardware platform proposed in this embodiment may include but is not limited to:

[0114] Step S41, in response to an FPGA hardware platform access request, output management configuration files corresponding to each of the multiple FPGA hardware platforms connected to the FPGA server;

[0115] Step S42, in response to a selection operation on the management configuration file, execute the selected management configuration file and collect the hardware operating status information of the first FPGA hardware platform;

[0116] Regarding the implementation methods of Step S41 and Step S42, reference may be made to the corresponding descriptions in the foregoing embodiments, and details are not repeated herein. It should be noted that the hardware operating status information of the collected FPGA hardware platform includes but is not limited to the information content listed above, that is, the content of the hardware operating status information may include but is not limited to one or more combinations described in each of Steps S21 - S24, and can be determined according to actual access requirements.

[0117] Step S43, store the collected hardware operating status information in a log storage manner;

[0118] For the hardware operating status information of each of the above - collected first FPGA hardware platforms, it can be stored in the form of a log, so that each piece of collected hardware operating status information is configured with the corresponding collection time (i.e., timestamp), can record the corresponding hardware operating status information in the order of events, and can also analyze the actual usage of the FPGA hardware platform in combination with the collection time.

[0119] In practical applications, for each first FPGA hardware platform, a corresponding log file can be configured to store the hardware operation status information collected for the first FPGA hardware platform, so that each FPGA hardware platform corresponds to a log file. In this log file, the collected hardware operation status information is sequentially recorded in the order of the collection time (such as the timestamp field). The present application does not limit the information storage method in the log file.

[0120] Step S44: Analyze the hardware operation status information to obtain the hardware operation status of the first FPGA hardware platform.

[0121] In the embodiments of the present application, for each first FPGA hardware platform that needs to be managed currently, after collecting the hardware operation status information of the corresponding first FPGA hardware platform according to the method described above, it can be directly analyzed to obtain the corresponding hardware operation status. The status represented / reflected by each hardware operation status information described in Embodiment 2 above can be referred to. For example, by analyzing the address change information of the currently executed instruction, the correctness of the corresponding program execution flow and the jump timing of the CPU pointer can be determined, and situations such as deadlocks or data competitions caused by shared resource conflicts can be detected in a timely manner; or the identifiers of the AXI bus collected (such as ARVALID, BRESP, and RRESP, etc.) can be analyzed to determine the corresponding represented status / operation (such as request read operation, write operation completion status, access permission error during transmission, etc.); by analyzing the change of the address bits of the register, the currently accessed register can be determined and the corresponding operation behavior can be determined; by analyzing the status information of each subsystem, the processing status, memory status, peripheral communication status, clock status, and interrupt status of the corresponding subsystem can be determined, and the analysis results described in the corresponding part of the above embodiments can be referred to.

[0122] In some other embodiments, the present application can also store the hardware operation status information of each first FPGA hardware platform to be managed according to the log storage method, and output and display the prompt information for the hardware operation status of the corresponding first FPGA hardware platform for the user to select whether to display the hardware operation status of each first FPGA hardware platform. In response to the confirmation operation input by the user, the hardware operation status information of the corresponding first FPGA hardware platform is read again, and its hardware operation status is analyzed. The present application does not limit the trigger condition for executing Step S44, which can be determined according to the situation.

[0123] Step S45: Send the hardware operation status of the first FPGA hardware platform to the system server to realize the visual display of the hardware operation status.

[0124] For the hardware operating status of the first FPGA hardware platform obtained from the above analysis, in order to facilitate users to intuitively understand the hardware operating status, it can be sent to the system server, and the system server can visualize it. For example, the hardware operating status of the first FPGA hardware platform can be displayed in a text description manner on the status query interface, or the hardware operating status of the first FPGA hardware platform can be converted into visualization data in the form of charts, curves or other display methods, and then the system server can visualize the hardware operating status of the first FPGA hardware platform according to the corresponding display method. This application does not limit the visualization method.

[0125] Combined with the above analysis, referring to Figure 5 the schematic diagram of the system architecture applicable to the FPGA hardware platform management method proposed in this application shown in Figure 5 order to realize the intelligent management of large-scale FPGA hardware platforms (such as

[0126] the FPGA hardware platforms 1 to n shown in

[0127] This application does not limit the value of n), the management configuration files configured for each FPGA hardware platform are pre-loaded into the FPGA server in advance, so that the FPGA server has the ability to monitor the hardware operating status corresponding to each FPGA hardware platform, and provides an entry for users to choose whether to monitor the hardware operating status of the FPGA hardware platform, and develops the management configuration files corresponding to each FPGA hardware platform for users. By selecting and executing one or more management configuration files that need to be monitored corresponding to the first FPGA hardware platform, the monitoring of the hardware operating status of the corresponding first FPGA hardware platform is realized, that is, the hardware operating status information of the first FPGA hardware platform is automatically collected, and the hardware operating status of the corresponding first FPGA hardware platform is automatically analyzed and determined. Figure 6As shown, the Xtor component (a key component for generating and sending protocol signals, which can be used in this application to convert monitoring logic into data packets conforming to a bus / interface protocol, such as USB data packets) sends the monitoring logic to the DWC (DesignWareCore, a type of USB controller IP core) controller through the BUS bus and the DUT (Device Under Test) backdoor. After protocol conversion (such as converting USB data packets into AXI data packets), it is output. Through the DMA operation device according to the AXI protocol, the monitoring logic that supports the AXI protocol is injected into the DUT device. That is, through this backdoor access method, the monitoring logic is written into the FPGA server so that during the execution of the corresponding management configuration file, the hardware operation status information of the corresponding FPGA hardware platform can be collected in real time according to this monitoring logic, such as Figure 3 the four types of information shown, and the usage of the corresponding FPGA hardware platform is determined through analysis.

[0128] It should be understood that for the structure of implementing data acquisition of the FPGA hardware platform, such as Figure 6 shown, in addition to the monitoring logic transmission process described above, it also includes other functions such as implementing data storage (such as FPGA DDR), communicating with other devices, and installing software. The implementation process is not described in detail in this application. In addition, for the bus protocols supported by the FPGA hardware platform, in addition to the AXI bus protocol, it also supports (Universal Asynchronous Receiver / Transmitter, a general asynchronous serial communication protocol) and (Joint Test Action Group, a standard interface and protocol for testing and debugging integrated circuits), etc. In the FPGA, the UART interface can be used to implement data interaction with external devices, convert parallel data into serial data for sending, and at the same time convert serial data into parallel data when receiving. The interface can be used for chip-level testing, debugging, and troubleshooting, such as testing, debugging, and troubleshooting the chip functions burned into the FPGA device.

[0129] Based on the above description, such as Figure 5As shown, the present application sends the hardware operation status of each first FPGA hardware platform obtained by automatic analysis to the system server, and realizes visual display through the system server, enabling users to intuitively see the hardware operation status of the first FPGA hardware platform. Combining the relevant descriptions of the above embodiments, the hardware operation status may include various aspects of the operation status inside the corresponding first FPGA hardware platform. Users can comprehensively and accurately understand the usage of the current first FPGA hardware platform without online communication with other personnel using the internal devices of the first FPGA hardware platform, which saves time and effort and has high efficiency. It also avoids situations where the usage of the first FPGA hardware platform summarized by users is inaccurate due to problems such as understanding errors in manual communication, ensuring the accuracy and reliability of the usage of the FPGA hardware platform obtained in the present application.

[0130] In some embodiments, to improve data transmission security, during the implementation of step S45, the hardware operation status of the first FPGA hardware platform can be compiled according to the Secure Shell (SSH) protocol using a preset compilation language to obtain a data transmission script. Then, by running the data transmission script, the hardware operation status of the corresponding first FPGA hardware platform is sent to the system server. In this implementation process, the SSH protocol library that supports functions such as encrypted connection and text transmission can be used to securely send the hardware operation status of the FPGA hardware platform to the system server for visual display.

[0131] Optionally, the above-mentioned preset compilation language can be Python. Correspondingly, the data transfer script can be a Python script. In practical applications, a Python script can be written by using an SSH protocol library (such as the Paramiko library) and the hardware operating status of the FPGA hardware platform to be transferred. The Python script can include, but is not limited to, code for implementing the following processes: configuring connection information between the FPGA server and the system server (such as the IP address, username, password, SSH port number, communication path, and file directory for storing transferred content of the system server), the storage path of the hardware operating status of the FPGA hardware platform stored locally, creating an SSH client to connect to the system server, creating an SFTP (SSH File Transfer Protocol) client, securely sending the hardware operating status of the FPGA hardware platform (which can be recorded by a file) to the system server, closing the SFTP and SSH connections, and can also check the transferred content to determine whether the system server has the hardware operating status of the FPGA hardware platform for this transfer. In this way, by running this Python script, the analyzed hardware operating status of the FPGA hardware platform can be securely sent to the system server for visual display according to the described processing process. It should be noted that the implementation method for transferring the hardware operating status of the FPGA hardware platform includes, but is not limited to, the implementation method described above.

[0132] In some embodiments, the server side can accurately obtain the actual usage of each FPGA hardware platform according to the above method. In this way, when a user requests to use FPGA hardware for chip function verification, the hardware resources of the FPGA hardware platform can be reasonably allocated to the user, enabling the user to complete the chip function verification as soon as possible. Especially when the hardware resources of the FPGA hardware platform requested by the user are scarce (such as the available hardware resources are less than the resource threshold, and this resource threshold is a relatively small value), the system server can, based on the current usage of each FPGA hardware platform (such as the visually displayed hardware operating status, or the hardware operating status of the FPGA device related to the chip function to be verified), allocate the FPGA device of the FPGA hardware platform with sufficient resources to the chip function to be verified requested by the user, that is, achieve reasonable allocation / scheduling of FPGA hardware resources, avoid the user waiting in line for a long time for the FPGA device with scarce hardware resources, realize the timeliness of verification, and also avoid the hardware usage risks brought by misoperating the FPGA hardware platform.

[0133] Based on the above analysis, referring to Figure 7 the schematic flowchart of the fourth optional embodiment of a method for managing an FPGA hardware platform proposed in the present application shown in Figure 7As shown, the FPGA hardware platform management method may further include the following steps:

[0134] Step S71: In response to a verification request for a function to be verified, determine multiple candidate FPGA hardware platforms that support the function to be verified;

[0135] Step S72: Based on the hardware operating status of each of the current multiple candidate FPGA hardware platforms, select a target FPGA hardware platform for the function to be verified from the multiple candidate FPGA hardware platforms;

[0136] Step S73: Control the target FPGA hardware platform to run the function to be verified;

[0137] In the chip function verification application based on the FPGA hardware platform, after the tester determines the FPGA device required for the function to be verified and the version of the FPGA hardware platform where it is located, this application can send a corresponding verification request to the FPGA server to request to use the FPGA device inside the FPGA hardware platform of the corresponding version. The verification request may include the version identifier or platform identifier of the FPGA hardware platform to be used, and may also include the device identifier of the actually used FPGA device, etc. Since the FPGA server has obtained the usage status (hardware operating status) of each current FPGA hardware platform according to the method described above, it can determine the current usage status of the FPGA hardware platform with this identifier, or the current usage status of the FPGA device with the device identifier, so as to determine whether the hardware resources of the current FPGA hardware platform / device can support the verification of the requested function.

[0138] In this way, in the case where the hardware resources of the requested FPGA hardware platform / device are insufficient to support the function verification, it is possible to promptly reallocate an FPGA hardware platform / device with sufficient hardware resources for this verification request to implement the verification of the requested function, without having to wait in line for some hardware resources of the requested FPGA hardware platform / device to be released and then continue to use the FPGA hardware platform / device to implement the verification of the requested function.

[0139] Based on the above analysis, in some embodiments, when the hardware resources of the FPGA hardware platform / device requested for use are insufficient, corresponding prompt information can be fed back to the initiating end side of the verification request to inform the tester that the hardware resources of the FPGA hardware platform / device requested for use this time are insufficient, whether to queue up and wait to use the FPGA hardware platform / device, and the number of request ends currently queuing up to use the FPGA hardware platform / device, etc. The tester can choose to queue up and wait according to the actual situation, or end the current verification request, or choose other FPGA hardware platforms / devices to initiate a verification request again, etc. Or, according to the method described below, the tester can request the server side to allocate FPGA hardware resources for it independently to implement the verification of the function to be verified. The implementation process of each situation in this application will not be elaborated in detail.

[0140] It should be noted that in the above verification request initiated by the tester, it is also possible not to specify the FPGA hardware platform / device, but only to describe the function to be verified. The FPGA server directly allocates an FPGA hardware platform / device with sufficient hardware resources for it according to the verification functions actually supported by each FPGA hardware platform. This method reduces the professional requirements for the tester and does not require the tester to know which FPGA devices / hardware platforms are needed to verify the chip function.

[0141] In the process of allocating an FPGA hardware platform / device with sufficient hardware resources for the function to be verified, in a possible implementation, based on knowing the functions supported by different FPGA hardware platforms respectively, after determining the function to be verified for which verification is requested, the candidate FPGA hardware platforms that support the implementation of the function to be verified can be determined through comparison. It should be understood that if the types of verification functions supported by each FPGA hardware platform are basically the same, this application can also directly use each FPGA hardware platform integrated in the FPGA server as the candidate FPGA hardware platform, and then combine the actual hardware operation status to achieve reasonable allocation of hardware resources.

[0142] For the hardware resource allocation method between different FPGA hardware platforms, it can be implemented by means of resource balancing or random allocation, etc. It can also be combined with the resource usage habits (such as entering the peak usage period or ending the usage at a specific time to release the currently occupied hardware resources) counted by each FPGA hardware platform, or implemented according to the above-mentioned identifiers included in the verification request. This application does not make any restrictions. Thus, reasonable allocation of FPGA hardware resources for each verification request can be achieved, avoiding allocating an FPGA hardware platform / device with insufficient hardware resources, which may lead to the inability to implement the requested function verification, and at the same time reducing the utilization rate and usage efficiency of the FPGA hardware platform / device with sufficient hardware resources.

[0143] Taking the resource balanced allocation method as an example for illustration, according to the respective hardware operating states of multiple current candidate FPGA hardware platforms, the available hardware resources for implementing the function to be verified are determined. One FPGA hardware platform with the most available hardware resources is selected as the target FPGA hardware platform, and the target FPGA hardware platform is controlled to run the function to be verified to determine whether it meets the expected design. This application does not elaborate on the implementation method of how to implement chip function verification on the FPGA hardware platform. It can be seen that in the large-scale FPGA hardware platform usage scenario, through reasonable allocation of FPGA hardware resources, this application avoids the queuing waiting time on the request function verification side, improves the usage efficiency of FPGA devices, and reduces the communication cost.

[0144] It should be understood that according to the method described above, this application can further determine the usage conditions (such as available resources) of each candidate FPGA device for implementing the function to be verified based on the hardware operating states corresponding to each candidate FPGA hardware platform. Combining with the expected amount of resources used to implement the function to be verified, a target FPGA device for the function to be verified is selected from each candidate FPGA device, which can be one or more candidate FPGA devices. Subsequently, the tester can be notified to burn the function to be verified into the target FPGA device to implement the verification of the function to be verified on the corresponding FPGA hardware platform. The implementation process of the function verification is not elaborated in this application.

[0145] Step S74: Execute the management configuration file corresponding to the target FPGA hardware platform, and collect the hardware operating state information of the target FPGA hardware platform;

[0146] Following the above analysis, during the process of using the target FPGA hardware platform for function verification, the hardware operating state information of the target FPGA hardware platform can be monitored simultaneously to determine whether the function verification process is correct by analyzing the hardware operating state of the target FPGA hardware platform. If there are any abnormalities, they can be discovered and resolved in a timely manner. The implementation process of step S74 can refer to the description of the corresponding part of the above embodiment, and will not be elaborated in this embodiment.

[0147] Optionally, during the process of using the target FPGA hardware platform for function verification, it is not required to necessarily trigger the real-time monitoring of the hardware operating state of the target FPGA hardware platform. This application can also be based on the method described in the above embodiment, and the user can independently choose whether to monitor the hardware operating state of the target FPGA hardware platform. When it is determined that monitoring is required, then select to execute the corresponding management configuration file; otherwise, the process can be ended without executing step S74.

[0148] Step S75: Determine multiple pre-configured hardware operating state relation tables for the target FPGA hardware platform;

[0149] Step S76: Query the corresponding hardware operation status relation table based on at least one piece of collected hardware operation status information, and determine the hardware operation status of the target FPGA hardware platform.

[0150] In a possible implementation, for the analysis process of various hardware operation status information of the FPGA hardware platform collected in real time, in order to reduce the online analysis time and resource consumption, this embodiment proposes to determine the actual status of the internal devices / functional modules of the corresponding FPGA hardware platform when each piece of hardware operation status information is of different contents through a large number of pre-experiments or based on predefined methods. For example, what status does ARVALID, AWVALID, WREADY, and BRESP of the AXI bus represent respectively; what status does the CPU pointer jump frequency represent when it is in range 1, range 2, range 3, etc.

[0151] After that, the hardware operation statuses corresponding to different hardware operation status information in the same type of hardware operation status information can be recorded in the corresponding hardware operation status relation table, which can be in the form of, for example, an Excel table, a CSV (Comma-Separated Values) file, a Json file, a database, or a Markdown file. Different FPGA hardware devices can store a hardware operation status relation table correspondingly. In this way, after the hardware operation status information of a certain FPGA hardware platform is actually collected, the corresponding hardware operation status relation table can be directly queried to quickly determine the hardware operation status of the FPGA hardware platform, that is, the hardware operation status recorded corresponding to the actually collected hardware operation status information. It should be understood that the determination of the hardware operation status of the first FPGA hardware platform for request management in the above embodiment can also be implemented by, but not limited to, this table lookup method.

[0152] Step S77: Send the hardware operation status of the target FPGA hardware platform to the system server to achieve the visual display of the hardware operation status.

[0153] Regarding the implementation method of Step S77, reference can be made to the description of the corresponding part in the above embodiment, and this embodiment will not elaborate here.

[0154] In some embodiments, in combination with Figure 8Schematic diagram of the architecture of the system server shown. The virtual Linux system therein can provide the operating environment for the system server, host services such as Django and Nginx, ensure system stability and resource isolation. The VUE front end provides an interface for direct interaction with testers, renders the login page and data display, and communicates with the Django backend through the API (Application Programming Interface). The Nginx proxy belonging to the large port is used to process HTTP / HTTPS requests and reverse proxy to Django (this process can be implemented through the Nginx proxy of the small port and the Uwsgi web server to handle concurrent requests and optimize the performance of Python applications. The front-end static resources in this process can be stored in the static Static files), or directly return to the VUE front end. The Nginx proxy belonging to the small port can be used to manage static files or perform load balancing. These two Nginx proxies can ensure external access to the system server through the IP port mapping method. Among them, the Django backend service program can handle business logics such as user authentication (login) and data query, interact with the front end through the API, and connect to the database to read and write information.

[0155] Based on this, the FPGA server reports the hardware operating status of the FPGA devices inside each FPGA hardware platform to the system server according to the method described in the above embodiments, such as Figure 8 implemented by the SSH transmission or the communication method based on the Python Modbus protocol. The system server can write the received hardware operating status of the FPGA devices inside each FPGA hardware platform into the database for storage for subsequent reading.

[0156] In practical applications, testers use terminal devices (such as laptops or industrial control computers, etc.) to connect to the system server, output the FPGA hardware operating status query interface provided by the VUE front end, and display the hardware operating status of any one or more FPGA hardware platforms requested to be queried in this interface. In this way, when chip function verification is required, the FPGA hardware platform / device with sufficient hardware resources can be selected accordingly to implement this function verification. The implementation process is not described in detail in this embodiment.

[0157] Based on this, referring to Figure 9 the schematic flowchart of the optional Embodiment 5 of the FPGA hardware platform management method proposed in this application shown, in the FPGA hardware platform management method described in the above embodiments, when storing the hardware operating status information of one or more FPGA hardware platforms in the form of logs, the hardware operating status of any FPGA hardware platform can also be queried and displayed according to the method shown in Figure 9 as follows:

[0158] Step S91: In response to a query request for the second FPGA hardware platform, determine the target status type of the second FPGA hardware platform for which the query is requested;

[0159] Step S92: According to the hardware operation status relationship table corresponding to the second FPGA hardware platform and the target status type, select at least one piece of hardware operation status information corresponding to the target status type from the stored hardware operation status information corresponding to the second FPGA hardware platform;

[0160] Step S93: Analyze at least one piece of hardware operation status information and output the hardware operation status of the second FPGA hardware platform.

[0161] In the embodiment of the present application, the second FPGA hardware platform can be any one or more of multiple FPGA hardware platforms integrated in an FPGA server. When the present application requests to manage the second FPGA hardware platform, it can directly output different types of hardware operation statuses of the internal devices of the second FPGA hardware platform according to the method described in Embodiment 1 above, and can output different hardware operation statuses in one or more visualization forms.

[0162] In a possible implementation, the present application can also query a specific status (which can be denoted as the target status) of the internal devices of the FPGA hardware platform according to actual needs, such as querying the usage frequency of FPGA device 1, querying the current status of subsystems A and B, etc. In this case, the target status identifier / type to be queried can be carried in the initiated query request, so as to query the corresponding hardware operation status relationship table of the corresponding FPGA hardware platform, determine at least one piece of hardware operation status information corresponding to the current target status type, analyze it to obtain the corresponding hardware operation status, and send it to the system server for visualization display, such as displaying it through the interface of the VUE front end.

[0163] In some embodiments, in combination with the above analysis, in Figure 8In the overall architecture of the Vue front-end, Nginx proxy, and Django back-end of the system server shown, this application integrates the FPGA server of the FPGA hardware platform with functions such as remote control and instant messaging software (such as Teams, WeChat Mini Programs, DingTalk, or X-Meeting, etc.) through a virtual Linux system, database, and web server, enabling the system server to support real-time monitoring of the operating status of internal devices of the FPGA hardware platform, remote operation, and notification of resource queuing situations. For example, based on the hardware resource allocation results described above, the determined queuing results, or prompt messages such as insufficient hardware resources of the requested FPGA hardware platform / device, they are sent to the instant messaging accounts of testers through methods such as emails, text messages, or audio data. For example, the prompt message is obtained through the Django back-end service program and sent to the Teams account of the tester. Among them, regarding the queuing results of FPGA hardware resources and their prompt methods, they can be implemented based on the existing functions of the queuing system, including but not limited to Figure 8 the described architecture.

[0164] Based on the above analysis, on the basis of the FPGA hardware platform management methods described in the above embodiments, it is also possible to respond to a remote control instruction for any FPGA hardware platform and control the FPGA hardware platform to perform corresponding operations according to the hardware operating status of the FPGA hardware platform, such as remote power management, exception maintenance, or function verification control, or secondary development / function configuration of a certain FPGA hardware platform, which can be determined according to actual needs.

[0165] In addition, it is also possible to respond to a lock request for any FPGA hardware platform, lock the hardware resources of the FPGA hardware platform to reject the usage request of the FPGA hardware platform, reduce the risk brought by misoperations, and reduce the influence among different testers using the FPGA hardware platform. It is also possible to notify testers of the available resources of the FPGA hardware platform in real time according to the method described above to avoid the hardware usage risk brought by misoperating the platform.

[0166] In addition, this application can realize the interconnection between FPGA devices inside different FPGA hardware platforms to achieve corresponding function verification or other control operations, that is, respond to an FPGA device interconnection request for multiple FPGA hardware platforms and control the data interaction between the multiple FPGA devices requested to be interconnected. Combined with Figure 8In the system architecture shown, data interaction can be achieved between different FPGA device ends through the system server to meet the actual application requirements. For example, the function of a certain designed chip needs to be realized by the cooperation of specific FPGA devices inside different versions of FPGA hardware platforms. This requires the interconnection of these multiple specific FPGA devices to verify the function of the chip. The verification process can refer to the description of the corresponding part of the above embodiments, and this embodiment will not be elaborated here.

[0167] Combined with the FPGA hardware platform management method provided by the embodiments of the present application introduced above, the device for executing the above FPGA hardware platform management method will be introduced below.

[0168] Referring to Figure 10 , which is the structural schematic diagram of the FPGA hardware platform management device proposed by the embodiments of the present application. As Figure 10 shown, the device may include:

[0169] The first output module 101 is configured to output the management configuration files corresponding to each of the multiple FPGA hardware platforms connected to the FPGA server in response to an FPGA hardware platform access request;

[0170] The acquisition module 102 is configured to execute the selected management configuration file in response to a selection operation on the management configuration file, and acquire the hardware operation status information of the first FPGA hardware platform; the first FPGA hardware platform refers to the FPGA hardware platform corresponding to the selected configuration file;

[0171] The second output module 103 is configured to analyze the hardware operation status information and output the hardware operation status of the first FPGA hardware platform; the hardware operation status includes the operation status of different FPGA devices in the first FPGA hardware platform.

[0172] Those skilled in the art can understand that the functions and technical effects of each module in the above device embodiments are equivalent to the corresponding steps described in the foregoing method embodiments. The specific implementation details can refer to the description of the method part and will not be elaborated here.

[0173] The embodiments of the present application also provide a computer program product, including computer-readable instructions. When the computer-readable instructions run on an electronic device, the electronic device is enabled to implement any FPGA hardware platform management method provided by the embodiments of the present application.

[0174] The embodiments of the present application also provide a computer-readable storage medium. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device is enabled to implement any FPGA hardware platform management method provided by the embodiments of the present application.

[0175] Refer to Figure 11 , which is a schematic diagram of the hardware structure of an FPGA server proposed in this application. As analyzed above, as Figure 11 shown, the FPGA server may include but is not limited to: at least one communication component 111, at least one memory 112, and at least one processor 113, where:

[0176] The at least one communication component 111, the at least one memory 112, and the at least one processor 113 can communicate via a bus. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 11 only a single bidirectional line is shown in , but it does not mean that there is only one bus or one type of bus.

[0177] The communication component 111 can be used to transmit the management configuration files corresponding to each of the multiple FPGA hardware platforms, the hardware operation status information, and the analyzed hardware operation status of each FPGA hardware platform, etc., as well as various intermediate data generated during the implementation of the FPGA hardware platform management method proposed in the embodiments of this application, and to implement data or instruction transmission between the internal components of the electronic device, depending on the situation.

[0178] Based on this, in the embodiments of the present application, the communication component 111 may include communication components corresponding to one or more wireless communication methods such as WIFI, Bluetooth, 5G / 6G, Global System of Mobile communication (GSM), General Packet Radio Service (GPRS), etc., so that the FPGA server can implement data transmission with other devices (such as system servers, terminal devices) through this communication component. Of course, in order to implement data transmission between the various components inside the FPGA server, the communication component 111 may also include one or more interfaces that support wired communication methods, such as a general-purpose input / output (GPIO) interface, a USB interface, a universal asynchronous receiver / transmitter (UART) interface, etc., in one or more combinations. The present application does not limit the component structure of the communication component 111 to implement this function and its corresponding communication transmission mechanism.

[0179] The memory 112 can be used to store multiple computer instructions for implementing the FPGA hardware platform management method proposed in the embodiments of the present application. The processor 113 can load and execute the computer instructions to implement the FPGA hardware platform management method proposed in the embodiments of the present application. The implementation process can refer to the description of the corresponding embodiments below, and this embodiment will not be described here.

[0180] In the embodiments of the present application, the memory 112 may include storage media such as floppy disks, USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs. The processor 113 may include any one or more combinations of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), a digital signal processor (DSP), a tensor processing unit (TPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and other dedicated neural network accelerators.

[0181] It should be understood that Figure 11 the structure of the FPGA server shown does not constitute a limitation on the FPGA server in the embodiments of the present application. In actual applications, the FPGA server may include more or fewer components than Figure 11 those shown, or combine certain components, and the present application will not give a detailed example one by one.

[0182] In addition, it should be noted that the device embodiments described above are only illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the device embodiments provided in the present application, the connection relationships between the modules indicate that they have a communication connection, which can be specifically implemented as one or more communication buses or signal lines.

[0183] Through the description of the above embodiments, in the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, or data center to another website, computer, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a data center integrating one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive SSD), etc.

[0184] In addition, the various embodiments in this specification are described in a progressive or parallel manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the devices, FPGA servers, products, and media disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

Claims

1. A method for managing an FPGA hardware platform, the method comprising: Responding to an FPGA hardware platform access request, and outputting management configuration files corresponding to multiple FPGA hardware platforms connected to an FPGA server; Responding to a selection operation on the management configuration file, executing the selected management configuration file, and collecting hardware operation status information of a first FPGA hardware platform; the first FPGA hardware platform refers to the FPGA hardware platform corresponding to the selected management configuration file; Analyzing the hardware operation status information, and outputting the hardware operation status of the first FPGA hardware platform; the hardware operation status includes the operation status of different FPGA devices in the first FPGA hardware platform.

2. The method according to claim 1, wherein the collecting of the hardware operation status information of the first FPGA hardware platform includes at least one of the following: Collecting address change information of the currently executed instruction in the first FPGA hardware platform; the address change information reflects the current usage status of the first FPGA hardware platform; Collecting data transmission information between different functional modules in the first FPGA hardware platform; the data transmission information reflects the usage frequency of the corresponding functional module; Collecting access information of each functional module in the first FPGA hardware platform; the access information reflects the operation behaviors existing in the current first FPGA hardware platform; Collecting status information of each subsystem in the first FPGA hardware platform; the status information reflects one or more of the operation mode, resource utilization rate, communication status, and exception information of the corresponding subsystem.

3. The method according to claim 2, wherein the analyzing of the hardware operation status information to determine the hardware operation status of the first FPGA hardware platform includes: Determining multiple pre-configured hardware operation status relation tables for the first FPGA hardware platform; One of the hardware operation status relation tables includes the hardware operation status reflected by different hardware operation status information in the same type of hardware operation status information; Querying the corresponding hardware operation status relation table according to at least one of the collected hardware operation status information, determining the hardware operation status of the first FPGA hardware platform, and then outputting it.

4. The method according to claim 2, wherein the collecting of the address change information of the currently executed instruction in the first FPGA hardware platform includes: Monitoring the pointer jump of the processor in the first FPGA hardware platform; The collecting of the data transmission information between different functional modules in the first FPGA hardware platform includes: Collecting bus interface data of the first FPGA hardware platform; The collecting of the access information of each functional module in the first FPGA hardware platform includes: Monitoring the address bit change of each register accessed in the first FPGA hardware platform.

5. The method according to any one of claims 1-4, the method further comprising: Storing the collected hardware operation status information in a log storage manner; Analyzing the hardware operation status information and outputting the hardware operation status of the first FPGA hardware platform includes: Responding to a query request for a second FPGA hardware platform, determining the target status type of the second FPGA hardware platform for which the query is requested; According to the hardware operation status relationship table corresponding to the second FPGA hardware platform and the target status type, selecting at least one piece of hardware operation status information corresponding to the target status type from the stored hardware operation status information corresponding to the second FPGA hardware platform; Analyzing the at least one piece of hardware operation status information and outputting the hardware operation status of the second FPGA hardware platform.

6. The method according to any one of claims 1-4, wherein outputting the hardware operation status of the first FPGA hardware platform includes: Sending the analyzed hardware operation status of the first FPGA hardware platform to the system server to implement visual display of the hardware operation status.

7. The method according to claim 6, wherein sending the analyzed hardware operation status of the first FPGA hardware platform to the system server includes: According to the Secure Shell protocol, compiling the hardware operation status of the first FPGA hardware platform using a preset compilation language to obtain a data transmission script; Running the data transmission script to send the hardware operation status of the first FPGA hardware platform to the system server.

8. The method according to any one of claims 1-4, the method further includes: Responding to a verification request for a to-be-verified function, determining a plurality of candidate FPGA hardware platforms that support the to-be-verified function; According to the respective hardware operation statuses of the current plurality of candidate FPGA hardware platforms, selecting a target FPGA hardware platform for the to-be-verified function from the plurality of candidate FPGA hardware platforms; Controlling the target FPGA hardware platform to run the to-be-verified function.

9. The method according to any one of claims 1-4, the method further includes any one of the following: Responding to a remote control instruction for any one of the FPGA hardware platforms, controlling the FPGA hardware platform to perform corresponding operations according to the hardware operation status of the FPGA hardware platform; Responding to a locking request for any one of the FPGA hardware platforms, locking the hardware resources of the FPGA hardware platform to reject a usage request for the FPGA hardware platform; Responding to an FPGA device interconnection request for a plurality of FPGA hardware platforms, controlling data interaction between the plurality of FPGA devices requesting interconnection.

10. The method according to any one of claims 1-4, wherein: The management configuration file includes a monitoring logic for the hardware operation status of the corresponding FPGA hardware platform and configuration information for configuring the underlying environment of the corresponding FPGA hardware platform; The monitoring logic is pre-embedded into the corresponding FPGA hardware platform to collect the hardware operation status information of the corresponding FPGA hardware platform according to the monitoring logic.

Images