Interface interaction device, data interaction method, storage medium and electronic equipment

Abstract

The embodiment of the invention provides an interface interaction device, a data interaction method, a storage medium and electronic equipment, and the device comprises a macro definition configuration component which is used for configuring interface parameters and interface attributes of an interaction interface connected between engine equipment and a computer system; the plurality of first functional components are used for executing processing operation on the data transmitted by the interactive interface; and the bus interface functional component is used for performing address distinguishing operation on the data transmitted by the interactive interface so as to store the data to storage equipment, and allocating storage space for processing results obtained by the processing operation executed by the plurality of functional components. Through the method and the device, the problem that an interaction framework between software and hardware in related technologies affects the speed and accuracy of data interaction is solved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computers. Specifically, the present application relates to an interface interaction device, a data interaction method, a storage medium, and an electronic device. Background Art

[0002] With the continuous increase in the complexity of electronic systems, the interaction between software and hardware has become more complex and diverse. In the field of chip design, the software-hardware interaction interface is a key bridge connecting hardware devices and software programs. This interface ensures that software can control and monitor the status of hardware, while allowing hardware to provide necessary information to software. The design of the software-hardware interaction interface is crucial for the functionality, performance, reliability, and scalability of the entire system.

[0003] However, in related technologies, there are problems with compatibility, flexibility, performance, and maintainability in the design structure of software-hardware co-design, and a complete software-hardware interaction framework cannot be formed. As a result, it will affect the speed and accuracy of data interaction, increase latency and errors during data transmission, and reduce the overall operating efficiency of the system. Summary of the Invention

[0004] The embodiments of the present application provide an interface interaction device, a data interaction method, a storage medium, and an electronic device to at least solve the problem that the interaction framework between software and hardware in related technologies affects the speed and accuracy of data interaction.

[0005] According to an embodiment of the present application, an interface interaction device is provided, including: a macro definition configuration component for configuring interface parameters and interface attributes of an interaction interface connecting the engine device and the computer system, where the interface parameters and the interface attributes are both used to configure the interaction interface to have the ability to transmit communication requirements between the engine device and the control device in the computer system; a plurality of first function components for performing processing operations on the data transmitted by the interaction interface; and a bus interface function component for performing address differentiation operations on the data transmitted by the interaction interface to store the data in a storage device and allocate storage space for the processing results obtained from the processing operations performed by the plurality of function components.

[0006] In an exemplary embodiment, the multiple first functional components include: a data master module, a data slave module, and a control slave module. Among them, the data master module supports multiple groups of data master interfaces in the interaction interface and is used to send data generated between the computer system and the engine device; the data slave module supports multiple groups of data slave interfaces in the interaction interface and is used to receive data generated between the computer system and the engine device; the control slave module is used to receive configuration information of the computer system, where the configuration information is used to configure the functions of the functional components in the engine device.

[0007] In an exemplary embodiment, the interface interaction device further includes a configuration file heap, where the configuration file heap is connected to the multiple first functional components and is used to control the function interaction, information interaction, and status interaction of the engine device based on the processing operations of the multiple first functional components.

[0008] In an exemplary embodiment, the configuration file heap includes: a function register file heap, an interrupt register file heap, a performance statistics register file heap, a trace debug register file heap, and a storage module. Among them, the function register file heap includes registers for controlling the interface characteristics, interface functions, and interface status feedback of the multiple first functional components; the interrupt register file heap includes registers for controlling the exception interrupts and exception status feedback of the multiple first functional components; the performance statistics register file heap includes registers for controlling the performance statistics and performance status feedback in the engine device; the trace debug register file heap includes registers for controlling the trace debug and debug status feedback of the engine device; the storage module includes the storage space of the engine device.

[0009] In an exemplary embodiment, the computer system performs read and write operations on the configuration file heap through the control slave module and the bus interface functional component among the multiple first functional components.

[0010] In an exemplary embodiment, the configuration file heap is connected to the bus interface functional component through a static random access memory interface; the configuration file heap and the multiple first functional components exchange data through a first direct connection line.

[0011] In an exemplary embodiment, when the interrupt processing module in the interface interaction device writes interrupt error information to the interrupt register file heap, the interrupt register file heap and the interrupt processing module serially write interaction information through the register interface timing; or, when there is an operation error in the configuration file heap and the configuration file heap writes the interrupt error information to the interrupt processing module in the interface interaction device, the interrupt register file heap and the interrupt processing module serially write interaction information through the register interface timing.

[0012] In an exemplary embodiment, the storage module is connected to the engine function module in the interface interaction device through a memory interface. The data interaction between the storage module and the engine function module includes read and write operations. The engine function module and the control slave module perform arbitration operations on the access to the storage module.

[0013] In an exemplary embodiment, the interface interaction device further includes an engine function module. Among them, the engine function module is connected to multiple first function components through a first register interface and is connected to the configuration file heap through a second direct connection line. The engine function module is used for data interaction with multiple first function components and the configuration file heap.

[0014] In an exemplary embodiment, the interface interaction device further includes an interrupt processing module. Among them, the interrupt processing module is connected to the module in the engine device through a second register interface and is used to receive the interrupt request sent by the module in the engine device and perform interrupt processing and routing on the interrupt request.

[0015] In an exemplary embodiment, the interface interaction device further includes a performance statistics module. Among them, the performance statistics module is passively connected to the module in the engine device and is used to count the events generated by the module in the engine device. Among them, the performance statistics module supports multiple event types, supports input of multiple events, supports trigger sources with multiple trigger times, supports counting statistics with start clock cycle configuration, and supports integration of multiple general modules.

[0016] In an exemplary embodiment, the interface interaction device further includes a debug tracing module. Among them, the debug tracing module is connected to the module in the engine device and is used to track key events and information in the engine device. Among them, the debug tracing module supports integration of multiple tracing units and supports multiple types of tracing logs.

[0017] In an exemplary embodiment, the interface interaction device further includes a status management module, wherein the status management module is connected to the modules in the engine device and is used to perform a handshake between the status of the engine device and the status update request of the computer system.

[0018] In an exemplary embodiment, the interface interaction device further includes a signal monitoring module, wherein the signal monitoring module is used to output the signals in the engine device to the computer system, and the signal monitoring module supports frequency division output of clock signals and pulse width expansion output of high-level pulse signals.

[0019] In an exemplary embodiment, the interface interaction device further includes a status update request interaction circuit, wherein the status update request interaction circuit includes a main interface and a standby interface and is used to interact with multiple first functional components for status update requests.

[0020] In an exemplary embodiment, the interface interaction device further includes a queue control logic, wherein the queue control logic is used to process queue control information, status information, and system interaction information in the engine device, interact with multiple first functional modules and an interrupt processing module in the interface interaction device, and is used to implement data interaction based on the queue control information, the status information, and the system interaction information and exception interrupt processing with the interrupt processing module.

[0021] In an exemplary embodiment, the interface interaction device further includes a performance statistics module, wherein the performance statistics module is integrated in the configuration file heap and is used to count the events in the configuration file heap and support the processing of count overflow.

[0022] In an exemplary embodiment, the interface interaction device further includes a debugging and tracing module, wherein the debugging and tracing module is integrated in the configuration file heap and is used to trace the information in the configuration file heap and support log output control.

[0023] In an exemplary embodiment, the interaction interface includes at least one of the following: an interrupt interface, a register interface, a memory access interface, a queue interface, and a status handshake interface.

[0024] According to another embodiment of the present application, a data interaction method is provided, including: when the interface parameters and interface attributes of the interaction interface are configured through a macro definition configuration component, transmitting a data command to a functional component in an engine device through the interaction interface, where the interface parameters and the interface attributes are both used to configure the ability of the interaction interface to meet the communication requirements between the engine device and a control device in a computer system; responding to the data command through the functional component to process the data in the data command; sending the processing result to the control device through the interaction interface; where the interaction interface and the functional component are both deployed in an interface interaction device, and the interface interaction device is deployed in the engine device.

[0025] According to still another embodiment of the present application, a computer program product is further provided, including a computer program, and when the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0026] According to still another embodiment of the present application, a computer-readable storage medium is further provided, and a computer program is stored in the computer-readable storage medium, where the computer program is set to execute the steps in any one of the above method embodiments when running.

[0027] According to still another embodiment of the present application, an electronic device is further provided, including a memory and a processor, a computer program is stored in the memory, and the processor is set to run the computer program to execute the steps in any one of the above method embodiments.

[0028] Through the present application, since the parameters and attributes of the interaction interface between the engine device and the computer system are configured through the macro definition configuration component, it is ensured that the interface can meet the communication requirements of both parties. The setting of multiple first functional components and the bus interface functional component not only improves the efficiency of data processing, but also realizes the accurate storage of data and the reasonable allocation of results. Therefore, the problem that the interaction framework between software and hardware in the related art affects the speed and accuracy of data interaction can be solved. Description of the Drawings

[0029] Figure 1 is a schematic diagram of an optional interface interaction device according to an embodiment of the present application;

[0030] Figure 2 is a schematic diagram of the position of the interface interaction device in the engine device according to an embodiment of the present application;

[0031] Figure 3 is a schematic diagram of a data master control module according to an embodiment of the present application;

[0032] Figure 4It is a schematic diagram of the hardware structure of the engine function module according to an embodiment of the present application;

[0033] Figure 5 It is a schematic diagram of the hardware structure of the interrupt processing module according to an embodiment of the present application;

[0034] Figure 6 It is a schematic diagram of the hardware structure of the medium performance statistics module according to an embodiment of the present application;

[0035] Figure 7 It is a schematic diagram of the hardware structure of the debug tracing module according to an embodiment of the present application;

[0036] Figure 8 It is a schematic diagram of the hardware structure of the status management module according to an embodiment of the present application;

[0037] Figure 9 It is a schematic diagram of the hardware structure of the signal monitoring module according to an embodiment of the present application;

[0038] Figure 10 It is a hardware structure block diagram of the server device of a data interaction method according to an embodiment of the present application;

[0039] Figure 11 It is a flowchart of the data interaction method according to an embodiment of the present application. Detailed implementation manners

[0040] In the following, embodiments of the present application will be described in detail with reference to the accompanying drawings and in conjunction with the embodiments.

[0041] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence.

[0042] In this embodiment, an interface interaction device is provided. Figure 1 It is a schematic diagram of an optional interface interaction device according to an embodiment of the present application. As Figure 1 shown, the interface interaction device is deployed in the engine device in the computer system, and includes:

[0043] A macro definition configuration component 102, configured to configure the interface parameters and interface attributes of the interaction interface connecting the engine device and the computer system, wherein both the interface parameters and the interface attributes are used to configure the ability of the interaction interface to transmit the communication requirements between the engine device and the control device in the computer system;

[0044] A plurality of first function components 104, configured to perform processing operations on the data transmitted by the interaction interface;

[0045] The bus interface functional component 106 is used to perform address discrimination operations on the data transmitted by the interaction interface, so as to store the data in the storage device and allocate storage space for the processing results obtained by the processing operations performed by multiple functional components 104.

[0046] Optionally, the position of the interface interaction device in the engine device is as Figure 2 shown, where Figure 2 the Common Interface Architecture (abbreviated as CIA) in

[0047] Optionally, the macro definition configuration component 102 acts as a configuration manager in this embodiment. It sets and controls various parameters of the software and hardware interaction interface through predefined macro commands, including but not limited to data transfer rate, data bit width, address mapping, interrupt enable, handshake protocol type, etc. These macro definitions can be constant definitions in a hardware description language or parameter settings for an automated configuration script.

[0048] For example, data transfer rate configuration: The macro definition DEF_DATA_RATE can be set to different values to match the data transfer requirements between different types of hardware devices and computer systems. For example, for high-speed data transfer, DEF_DATA_RATE can be set to 500 MHz. Address mapping configuration: The macro definitions DEF_REG_ADDR_BASE and DEF_MEM_ADDR_BASE are respectively used to set the base addresses of registers and memories, thereby defining the address space division between the engine device and the computer system. This helps the system accurately locate the target resource when accessing different hardware resources. Interrupt enable configuration: Through the macro definition DEF_INT_ENABLE, it is possible to control whether a specific type of interrupt is enabled. For example, DEF_INT_ENABLE can be set to 1 to enable function interrupts, and set to 0 to disable function interrupts, so as to adapt to different application scenarios.

[0049] Optionally, the multiple first functional components 104 include various core modules responsible for data processing, control, and status feedback.

[0050] Optionally, the bus interface function component 106, i.e., the Bus Interface Function (BIF), is a module for data address differentiation and storage space management. It supports the bus interface function, mainly used for differentiating the addresses of operations received by the first function component and accessing different register sets or internal memories. It can, according to the address mapping rules set by the macro-defined configuration component, correctly store the data transmitted through the interaction interface into the corresponding registers or memories, and at the same time allocate storage space for the data processing results of other function components 104.

[0051] For example, for the address differentiation operation: the macro definitions DEF_REG_ADDR_RANGE and DEF_MEM_ADDR_RANGE respectively define the address ranges of registers and memories. When the computer system sends data through the Data Master interface, the BIF, according to these macro definitions, stores the data into the correct registers or memories. For storage space allocation: the BIF can also, according to the storage requirements configured by the macro definition, allocate specific storage spaces in the memory for the data processing results of components such as Function Kernel, Interrupt Kernel, QPA Kernel, and Trace Kernel. For example, the macro definition DEF_QPA_MEM_SIZE can be set to 1KB for storing the statistical results of the QPA Kernel.

[0052] Through this embodiment, since the parameters and attributes of the interaction interface between the engine device and the computer system are configured through the macro-defined configuration component, it is ensured that the interface can meet the communication requirements of both parties. The setting of multiple first function components and the bus interface function component not only improves the efficiency of data processing but also realizes the accurate storage of data and the reasonable allocation of results. Therefore, the problem that the interaction framework between software and hardware in the related art affects the speed and accuracy of data interaction can be solved.

[0053] In an exemplary embodiment, the multiple first function components include: a data master module, a data slave module, and a control slave module. Among them, the data master module supports multiple groups of data master interfaces in the interaction interface and is used to send the data generated between the computer system and the engine device; the data slave module supports multiple groups of data slave interfaces in the interaction interface and is used to receive the data generated between the computer system and the engine device; the control slave module is used to receive the configuration information of the computer system, where the configuration information is used to configure the functions of the function components in the engine device.

[0054] Optionally, in this embodiment, the data master module can be, for example, Figure 3 as shown inFigure 3 The shown Data Slave and control slave module can be, for example, Figure 3 the shown Control Slave. Among them, as Figure 3 shown, the Data Master supports multiple groups of Data Master interfaces, which are mainly used to send data information of the computer system. The key parameters and characteristics of the interfaces support macro definition, constant definition, and register configuration definition. The Data Slave supports multiple groups of Data Slave interfaces, which are mainly used to receive data information of the computer system. The key parameters and characteristics of the interfaces support macro definition, constant definition, and register configuration definition. The Control Slave supports the Control Slave interface, which is mainly used to receive configuration information of the computer system. The key parameters and characteristics of the interface support macro definition, constant definition, and register configuration definition.

[0055] For example, in a specific embodiment, multiple first functional components include a data master module (DataMaster), a data slave module (Data Slave), and a control slave module (Control Slave), which undertake the core tasks of data transmission and configuration management in the software and hardware interaction interface.

[0056] The Data Master is the initiator of data transmission. It controls the output flow of data and is used to send the data generated by the computer system to the engine device. In Figure 3 it, the Data Master supports multiple groups of Data Master interfaces, which means that it can process multiple data streams simultaneously and provide data transmission services for different functional requirements. For example, if there are multiple functional units in the engine device, the Data Master can send specific data packets to these functional units through different data master interfaces to achieve parallel processing or on-demand data allocation.

[0057] The Data Slave is used to receive data from the Data Master or other data sources and store it in the internal registers or memories of the engine device. In Figure 3 the shown embodiment, the Data Slave supports multiple groups of Data Slave interfaces, enabling it to process multiple input channels simultaneously, thereby improving the parallelism and efficiency of data reception. For example, the Data Slave interface can receive multiple data streams from the computer system. These data streams may contain different data types or be targeted at different functional modules, and the Data Slave needs to be able to correctly distinguish and process these data streams.

[0058] Control Slave is a module for receiving computer system configuration information and plays a key role in the communication between the engine device and the computer system. The control slave module can perform corresponding function settings on the functional components in the engine device according to the received configuration information. For example, in Figure 3 , the Control Slave interface may receive configuration parameters such as data processing rate, queue size, interrupt enable, etc., which are used to adjust the performance characteristics and operation modes of the engine device. The Control Slave module needs to support macro definitions, constant definitions, and register configuration definitions to meet flexible configuration requirements.

[0059] In this embodiment, the interaction methods of these modules may involve complex protocols and handshake mechanisms to ensure the correctness and synchronization of data transmission. For example, the Posted or Non-Posted data transmission protocol may be used between the Data Master and the Data Slave, and the most suitable data transmission method is selected according to different scenarios and requirements. In addition, the ControlSlave module may need to interact with the BIF (Bus Interface Function) module through the register interface to achieve address differentiation of configuration information and precise control of functional components.

[0060] Through the collaborative work of these modules in this embodiment, the software and hardware interaction interface can provide efficient and reliable data transmission and configuration management services, meeting the complex data processing and system control requirements in modern multi-self-developed engine systems. The design and implementation of these modules follow the principles of modularity and configurability, enabling the interface device to adapt to different application environments and hardware configurations, with good scalability and compatibility.

[0061] In an exemplary embodiment, the interface interaction device further includes a configuration file heap, wherein the configuration file heap is connected to a plurality of first functional components and is used to control the function interaction, information interaction, and status interaction of the engine device based on the processing operations of the plurality of first functional components.

[0062] Optionally, the configuration file heap includes: a function register file heap, an interrupt register file heap, a performance statistics register file heap, a trace debug register file heap, and a storage module. The function register file heap includes registers for controlling the interface characteristics, interface functions, and interface status feedback of a plurality of first functional components; the interrupt register file heap includes registers for controlling the exception interrupts and exception status feedback of a plurality of first functional components; the performance statistics register file heap includes registers for controlling the performance statistics and performance status feedback in the engine device; the trace debug register file heap includes registers for controlling the trace debug and debug status feedback of the engine device; and the storage module includes the storage space of the engine device.

[0063] As Figure 3 shown, the FunctionRegFile in this embodiment includes multiple registers for controlling the interface characteristics of the Data Master, Data Slave, and Control Slave, as well as the control and status feedback registers for invoking the main functions of the interface engine. For example, the registers in FunctionRegFile can be used to set the data bit width, transfer mode (such as Posted or Non-Posted transfer), error handling strategy, etc. of the DataMaster interface. In addition, FunctionRegFile may also contain control registers related to the main functions of the engine, such as function enable, configuration parameters, status flags, etc., as well as registers for feedback on the execution status of functions, such as completion flags, error codes, progress status, etc.

[0064] The InterruptRegFile is used for interrupt control and status feedback, and also includes the control and status feedback registers for the queue in the Interrupt Kernel. It may contain control registers for setting interrupt enable, interrupt mask, interrupt clear, etc.; status registers for reporting interrupt status, queue full / empty status, error status, etc.; and queue control and status feedback registers related to the Interrupt Kernel. Through the InterruptRegFile, the system can configure and query the interrupt characteristics of the engine device to achieve timely response to abnormal events and status changes.

[0065] The QPARegFile for performance statistics is used to store control parameters and status information related to the performance statistics of the engine, such as the configuration of event counters, the start and end conditions of cycle statistics, the handling strategy for count overflow, etc. The registers in this part enable the system to collect the performance data of the engine device in a standardized manner, providing a basis for optimizing system design and improving performance.

[0066] The TraceRegFile for trace debugging is used to store control parameters and status information related to the trace debugging of the engine, such as log recording enable, log filtering rules, log storage location, etc. Through the TraceRegFile, the system can configure the behavior of the Trace Kernel and collect key information during the operation of the engine device for fault diagnosis and performance analysis.

[0067] The storage module can be the internal storage space of the engine device. For example, it can be a Static Random Access Memory (SRAM for short). It is used to store configuration information, queue data, intermediate calculation results, temporary caches, etc. Due to its static characteristics, SRAM can provide fast read and write operations and is an ideal choice for the storage module. The design of the storage module needs to consider capacity, access speed, power consumption, and data consistency to meet the storage requirements of the engine device. For example, the storage space field allocation can be set as follows: Function module related register field: 256KB. Interrupt handling module related register field: 2KB. Trace module related register field: 1KB. Performance statistics module related register field: 1KB. Storage space field: 764KB.

[0068] In a specific embodiment, the configuration of the configuration file heap includes: FunctionRegFile, InterruptRegFile, QPARegFile, TraceRegFile, and the storage space SRAM. The system performs read and write operations on registers and memories through the engine AHB Slave interface and the BIF module. The memory space supports the implementation of storage banks for both configuration information and queues. When an error or violation occurs during the register configuration process, the error status and related information are passed to the interrupt handling module.

[0069] Optionally, the computer system performs read and write operations on the configuration file heap through the control slave module and the bus interface function component in multiple first function components.

[0070] For example, the system performs read and write operations on registers and memories through the Control Slave interface of the engine and the BIF (Bus Interface Function) module. Among them, the Control Slave interface is used to receive configuration information and control commands from the system. The system (such as a CPU or a main controller) sends instructions through the Control Slave interface to read or update the register configuration inside the engine, and control the functional characteristics and operating status of the engine. The key parameters and characteristics of the Control Slave interface, such as data bit width, address range, control signals, etc., can be flexibly configured through macro definitions, constant definitions, and register configuration definitions to adapt to different hardware architectures and functional requirements.

[0071] The BIF module is a bus interface function module. Based on the control signals received by the Control Slave, it further parses and routes these signals to ensure that they correctly reach the target register or memory. The BIF module identifies the address information sent by the Control Slave interface through address decoding and directs read and write operations to the correct register or memory space. This address discrimination and routing function enables the system to access multiple registers and memory spaces inside the engine through a unified interface, improving the versatility of the interface and the convenience of operation.

[0072] Through the collaborative work of the Control Slave interface and the BIF module, the process of the system accessing registers and memory includes: The system sends read and write commands through the Control Slave interface, including the target address, data (for write operations), and control signals. After receiving this information, the BIF module performs address decoding to identify the address of the target register or memory. The BIF module routes the read and write commands to the corresponding register or memory space and executes read or write operations. For read operations, the data is returned from the register or memory to the BIF module and then fed back to the system through the Control Slave interface; for write operations, the data is written from the system to the register or memory through the Control Slave interface. Configuration and status feedback: The system configures and queries the status of the functional register file heap, interrupt register file heap, performance statistics register file heap, trace debug register file heap, and storage module through the above mechanism. For example, the system can set the parameters in the register file heap through the Control Slave interface to control the functional characteristics of the engine device; similarly, it can also read the status information in the register file heap to understand the operating status, performance status, debug information, etc. of the engine device.

[0073] Optionally, the configuration file heap is connected to the bus interface function component through a static random access memory interface; the configuration file heap exchanges data with multiple first function components through a first direct connection line.

[0074] In this embodiment, the connection between the configuration file heap and the bus interface function component (BIF) through a static random access memory (SRAM) interface, and the exchange of data between the configuration file heap and multiple first function components (such as Data Master, Data Slave, Interrupt Kernel, QPA Kernel, Trace Kernel, etc.) through direct connection lines are key strategies for achieving efficient data transmission and status management in the software and hardware interaction interface design.

[0075] The SRAM interface connection between the configuration file heap and the BIF module is mainly to achieve efficient reading and writing of registers and memory spaces. This connection method utilizes the high-speed access characteristics of SRAM to ensure that the system's access operations to the configuration file heap can be completed quickly without causing a significant decline in system performance. The design of the SRAM interface may involve the following key points: Address mapping: The address information sent by the system through the BIF module must be correctly recognized by the SRAM interface and mapped to specific registers or storage locations in the configuration file heap. Data transfer: The SRAM interface supports high-speed data transfer to ensure that the reading and writing operations of data between the system and the configuration file heap can be completed quickly, reducing data transfer latency. Control signals: The SRAM interface should also include control signals such as read / write enable, address valid, data valid, etc., for controlling data reading and writing and synchronization operations.

[0076] Optionally, the configuration file heap interacts with multiple first functional components through direct connections, mainly to achieve direct transmission of data and status information, improving system response speed and data processing efficiency. The characteristics of direct connection interaction are: Real-time: Since direct connections reduce protocol overhead and arbitration latency during data transmission, they can provide higher real-time performance and lower latency, which is crucial for control signals and status feedback that require high-speed response. Specificity: Direct connections are usually designed for specific modules or functions, which means they can be optimized for specific functional requirements. For example, the Function Kernel (functional module) and the configuration file heap may need to transmit control parameters and status information, while the Interrupt Kernel (interrupt handling module) may need to transmit interrupt enable status and interrupt signals. Signal integrity: The design of direct connections needs to consider signal integrity to ensure the accuracy and consistency of data under high-speed transmission conditions. This may involve techniques such as signal layout, wiring strategy, clock synchronization, and data verification.

[0077] When designing the software-hardware interaction interface, both the SRAM interface and direct connection interaction are selected according to different data transfer requirements and module characteristics. The SRAM interface is suitable for registers or memories that need to be accessed and configured frequently, while direct connection interaction is more suitable for the transmission of immediate control signals and status information.

[0078] In this embodiment, as Figure 3As shown, the hardware interaction methods between the register file heap (Register File & SRAM) and other modules include: The BIF and the register file use a register interface operation. The BIF and the memory use an SRAM interface operation. The register file and each module interact through direct connections, including the information sent from the register file to the input module and the status feedback from the module to the register file. When the interrupt processing module writes interrupt error information to the InterruptRegFile, the information is serially written using the register interface timing interaction. When there is an error in the register file operation, the register file writes interrupt error information to the interrupt processing module, and the information is serially written using the register interface timing interaction. The memory and the Function Kernel interact through a memory interface. The interaction between the Function Kernel and the memory is a read / write operation, and the Function Kernel and the Control Slave perform arbitration for accessing the memory.

[0079] Optionally, when the interrupt processing module in the interface interaction device writes interrupt error information to the interrupt register file heap, the interrupt register file heap and the interrupt processing module serially write the interaction information through the register interface timing; or, when there is an error in the register file heap operation and the register file heap writes interrupt error information to the interrupt processing module in the interface interaction device, the interrupt register file heap and the interrupt processing module serially write the interaction information through the register interface timing.

[0080] In this embodiment, the interaction between the interrupt processing module and the interrupt register file heap, especially the writing of error information, is achieved through the register interface timing interaction. This method mainly considers the reliability of data transmission and the synchronization of timing to ensure that interrupt information can be accurately recorded and processed. Among them, when processing interrupt error information, a serial writing mechanism is usually adopted, that is, the information is transmitted serially through the register interface. The main advantage of serial writing is to reduce the number of physical signal lines required, thereby reducing the complexity and cost of hardware design. At the same time, the serial writing mechanism can ensure the integrity and synchronization of data during transmission through precise timing control, avoiding timing problems and race conditions that may occur in parallel data transmission.

[0081] When the interrupt handling module writes error information to the interrupt register file heap, the timing interaction of the register interface plays a crucial role. The timing interaction includes the timing relationship of signals, clock synchronization, and the definition of data valid time, ensuring that data is received and stored at the correct time points. Specifically, the timing interaction may involve the following key points: Clock synchronization: The transmission and reception of data must be synchronized with a common clock signal to ensure that data is received at the correct position in each clock cycle. Data validity: When the information on the data line is transmitted, it must be received by the interrupt register file heap under the indication of the data valid signal to avoid receiving incorrect data at other time points in the clock cycle. Address and control signals: The address line and control signals (such as the write enable signal) must also comply with specific timing rules to ensure that data is written to the correct register location. Error information transfer: When the configuration file heap operation is incorrect, the error status and related information need to be immediately transferred to the interrupt handling module. Through the register interface timing interaction, the configuration file heap can send the error information to the interrupt handling module in a serial manner, ensuring that the interrupt handling system can quickly identify the error and take corresponding handling measures. This error information transfer mechanism is an important guarantee for the stability and reliability of the system, which can help the system recover in time when encountering problems and avoid further errors or system crashes.

[0082] Optionally, the storage module is connected to the engine function module in the interface interaction device through a memory interface. The data interaction between the storage module and the engine function module includes read and write operations, and the engine function module and the control slave module perform arbitration operations on the access to the storage module.

[0083] In this embodiment, the connection between the storage module and the engine function module is implemented through a memory interface. This connection method allows for efficient data read and write operations between the storage module and the function module. The design of the memory interface needs to consider the data transfer rate, capacity, and access control complexity. Especially when multiple control modules (such as DataMaster, Data Slave, Control Slave) need to access the same storage module, there must be a mechanism to arbitrate these access requests to ensure data consistency and access orderliness.

[0084] In an exemplary embodiment, the interface interaction device further includes an engine function module. Among them, the engine function module is connected to multiple first function components through a first register interface and connected to the configuration file heap through a second direct connection line. The engine function module is used to perform data interaction with multiple first function components and the configuration file heap.

[0085] Optionally, as Figure 4As shown in the figure, it is a schematic diagram of the hardware structure of the engine function module in this embodiment. The engine function module Function Kernel is a support function module that calls the core functions of the interaction interface device. Among them, for the logic blocks affected by macro definitions, the software and hardware interface design only implements the interface logic, and the arbitration, use, and transfer output of specific information are implemented by the internal engine function definition of Function Kernel, such as the arbitration of multiple Data Master inputs to FunctionKernel, the arbitration of multi-channel access to SRAM inside Function Kernel, etc. Among them, FunctionKernel receives the error information feedback by the Data Master controller through the register interface. Receives the error information feedback by the Data Slave controller through the register interface. Receives the data information feedback by the AXI Master through the Buffer or register, and Function Kernel drives the Data Master write operation to implement Posted or Non-Posted transmission. Receives the error information feedback by the ControlSlave controller through the register interface. Receives the error information feedback by the P Slv controller (State Monitor) through the register interface. Receives the input signal of the register file heap through the direct connection line, and outputs the status information to the register file heap through the register interface. The function exception interrupt information is output to the interrupt processing module through the register interface. Implements read and write operations on the queue control logic inside the Interrupt Kernel through the register interface. Reads and writes the queue storage content through the register interface or the memory interface. When the queue is the internal queue of the engine, the information such as full and empty implemented by the queue is directly connected and input to Function Kernel. Outputs the performance-related information to be counted to the performance statistics module through the direct connection line and the register interface. Obtains the alarm information of the performance statistics module through the register interface. Outputs the debug trace information to the debug trace module through the register interface. Obtains the alarm information of the debug trace module through the register interface. Interacts with the status management module through the request and response handshake method. Outputs the signals to be monitored by the system to the signal monitoring module through the direct connection line method.

[0086] Optionally, the function definition and interaction of the Function Kernel include: Implementation of the main logic functions of the engine: The Function Kernel is responsible for the core functional logic of the engine, such as data processing, algorithm execution, task scheduling, etc., and is the basis for the implementation of the engine device performance and functions. Data interface interaction: The Function Kernel interacts with the Data Master and DataSlave interface controllers to implement read and write operations of data. During this process, the Function Kernel receives feedback information on data transmission, including transmission status, data integrity, and error information, etc. When the Data Master or DataSlave interface feedbacks an error, the Function Kernel will immediately respond and pass the error status and relevant information to the interrupt handling module to trigger the corresponding error handling process. Control interface interaction: The Function Kernel receives operation feedback information from the Control Slave or BIF, including configuration status, execution results of control commands, etc. When the Control Slave or BIF interface feedbacks an error, the Function Kernel will also pass the error status to the interrupt handling module to ensure the stability and reliability of the system. Status and configuration interaction: The Function Kernel interacts with the configuration file heap to obtain and update control information and status information related to the engine functions, which includes function enabling, configuration parameters, status flags, etc., as well as possible queue control and status feedback. Interrupt management: The Function Kernel can generate function exception interrupt signals. When a function exception is detected inside the engine, it notifies the system through the interrupt signal and at the same time passes the relevant error status information to the interrupt handling module. In addition, the Function Kernel is also responsible for routing and processing warning information from the performance statistics module and the debug tracing module and passing it to the specified queue for subsequent processing. Queue interaction: The Function Kernel manages queue control information and status information and interacts with the system in a queue manner to ensure the orderly transmission and processing of data. Performance statistics interaction: The Function Kernel interacts with the performance statistics module, can generate key performance data, or pass internal signals to the performance statistics module for statistics to facilitate the monitoring and optimization of system performance. Debug tracing interaction: The Function Kernel passes debug information to the debug tracing module in a specified format to support system fault diagnosis and performance analysis. Status management: The Function Kernel interacts with the status management module, feedbacks the current engine status, or responds to requests from the status management module to ensure the accuracy and real-time nature of the engine status.Signal Monitoring: The Function Kernel sends the signals to be monitored by the system to the signal monitoring module for processing, providing an observation window for the system to observe the internal operating state of the engine.

[0087] Optionally, the internal mechanisms and macro definitions include: The internal logic design of the Function Kernel allows for flexible configuration through macro definitions. Macro definitions can affect multiple logical blocks of the Function Kernel, such as the data width of the Data Master interface, arbitration policies, SRAM access arbitration, etc. However, for the logical blocks affected by macro definitions, the software and hardware interface design only implements the interface logic, while the arbitration, use, and transfer of specific information are implemented by the internal engine functions of the Function Kernel. This means that although the interface design provides an interface that conforms to the macro definition, how to process this information internally, how to allocate access resources, and how to manage the data flow are all determined by the internal logic of the Function Kernel.

[0088] For example, when multiple Data Master interfaces input into the Function Kernel, the macro definition can specify the data width and communication protocol, but the arbitration logic of the data, the management of the data flow, and the error handling mechanism are implemented by the internal logic of the Function Kernel. The arbitration logic determines which request will be processed first when multiple Data Masters simultaneously request access to the Function Kernel, and how to handle conflicts between multiple requests. Data flow management involves data caching, queuing, and scheduling strategies to ensure that data can be correctly processed and transmitted. The error handling mechanism ensures that when an error occurs during data transmission, the Function Kernel can detect and respond in a timely manner to avoid data loss or corruption.

[0089] The internal mechanism design of the Function Kernel is one of the key technologies of the software and hardware interaction interface device. Flexible configuration of the interface logic is achieved through macro definitions, while the internal logic ensures the efficient implementation of functions and the stability of the system through precise design and optimization.

[0090] In a specific embodiment, the configuration of the Function Kernel is as follows: Implement the main logical functions of the engine. Interact with the AXI Master interface controller to implement data read and write operations and receive feedback information. When the interface feedbacks an error, make corresponding feedback and transfer the error status and related information to the interrupt handling module. Interact with the AXI Slave interface controller. When the interface feedbacks an error, make corresponding feedback and transfer the error status and related information to the interrupt handling module. Receive the operation feedback information from the AHB Slave interface controller or the BIF. When the interface feedbacks an error, make corresponding feedback and transfer the error status and related information to the interrupt handling module. Receive the operation feedback information from the PChannel Slave interface controller. When the interface feedbacks an error, transfer the error status and related information to the interrupt handling module. Interact with the configuration file heap about the relevant control information and status information of the engine function. Generate a function exception interrupt signal and related error status information and transfer them to the interrupt handling module. Maintain queue control information, status information, and system interaction information to implement queue-based interaction with the system. Interact with the performance statistics module to generate or directly transfer key signals to the performance statistics module for statistics. The unit in the performance statistics module generates an alarm message. After being fed back to the function module, it is routed to the specified queue by the function unit. Interact with the debug tracing module to generate the information to be traced in the specified format and transfer it to the debug tracing module. The tracing unit in the debug tracing module generates an alarm message. After being fed back to the function module, it is routed to the specified queue by the function unit. Interact with the status management module to feedback the current engine status to the status management module, or obtain the request from the status management module and make corresponding feedback. Interact with the signal monitoring module to send the signals to be monitored by the system to the signal monitoring module for processing.

[0091] In an exemplary embodiment, the interface interaction device further includes an interrupt handling module. Among them, the interrupt handling module is connected to the modules in the engine device through the second register interface and is used to receive the interrupt requests sent by the modules in the engine device and perform interrupt handling and routing on the interrupt requests.

[0092] Optionally, as Figure 5As shown, it is a schematic diagram of the hardware structure of the interrupt processing module in this embodiment. The hardware interaction methods of the interrupt processing module include: outputting error interrupts and function interrupts to the engine through a direct connection line; receiving input signals from the register file heap through a direct connection line; outputting status information to the register file heap through a register interface; obtaining system error information and alarm information from the Function Kernel through a register interface; obtaining control information of the function unit pair queue from the Function Kernel through a register interface; feedbacking relevant control status information of the queue to the Function Kernel through a direct connection line; sending counting and statistical information to the QPA Kernel through a register interface; sending information about the required level statistics of the queue to the QPA Kernel through a direct connection line; the QPA Kernel uniformly sends internal QPCC statistical overflow information to the Interrupt Kernel through a register interface; sending information to be tracked to the Trace Kernel through a register interface; the Trace Kernel uniformly sends internal TPCC lost log count overflow information to the Interrupt Kernel through a register interface; sending signals to be monitored to the Sig4Mon module through the upper-level method of the direct connection line.

[0093] Optionally, the function definition of the Interrupt Kernel includes: Queue control logic: The Interrupt Kernel is used to implement the main control logic of the queue, which includes queue initialization, enqueue and dequeue control of data elements, and management of queue overflow and idle states. In addition, the Interrupt Kernel can generate multiple functional interrupt outputs according to macro definitions, which means it can configure and control multiple queue events, such as queue full, queue empty, etc., and notify the system in the form of functional interrupts. Functional interrupt control: The Interrupt Kernel can implement the control of functional interrupts, including but not limited to interrupt routing, enable control, bitwise masking, and channel-by-channel clearing functions. Interrupt routing determines which part of the system the functional interrupt signal is sent to, while enable control and bitwise masking allow the system to enable or mask specific interrupt signals, and the channel-by-channel clearing function is used to clear the interrupt status of specific queue channels. Exception interrupt management: The Interrupt Kernel is also used for the control logic of internal exceptions in the engine, capable of generating error exception interrupt outputs, and implementing control operations on these exception interrupts, including enabling, bitwise masking, channel-by-channel clearing, and updating the exception interrupt status register, to ensure that the system can respond and handle exception events in a timely manner. Interaction with the configuration file heap: The Interrupt Kernel interacts with the configuration file heap to obtain and update control information and status information related to the interrupt processing module. This may include configuration parameters such as interrupt enable status, masking status, as well as status information such as queue status, exception status, etc. Interaction with the engine function module: The Interrupt Kernel obtains queue control information and status information from the Function Kernel, such as head pointer and tail pointer marks of the queue, remaining space of the queue, and exception status. At the same time, the Interrupt Kernel receives the system exception status information transferred by the Function Kernel to ensure that this information can be correctly processed and fed back. Performance statistics interaction: The Interrupt Kernel interacts with the performance statistics module (QPAKernel) to transfer queue-related performance data to the performance statistics module for statistics. This may include data such as the number of enqueues and dequeues of the queue, the number of queue status changes, etc. Debug tracing interaction: The Interrupt Kernel interacts with the debug tracing module (Trace Kernel) to transfer the information to be traced to the Trace Kernel in a custom format to support the debugging and tracing requirements of the system. Signal monitoring interaction: The Interrupt Kernel sends the signals to be monitored by the system to the signal monitoring module (Sig4Mon) for processing, providing external monitoring capabilities for signal status.The above function definition of Interrupt Kernel reflects its complexity and importance in the design of the software-hardware interaction interface. It not only manages the generation and transmission of interrupt signals, but also interacts with multiple functional modules to ensure the correctness of the data stream and the optimization of performance.

[0094] In a specific embodiment, the configuration of the interrupt processing module (Interrupt Kernel) is as follows:

[0095] Implement the main control logic for 32 groups of queues, generating 8 functional interrupt outputs. Implement control operations for functional interrupts, including interrupt routing, enabling, bitwise masking, clearing by channel, and updating the functional interrupt status register. Implement the internal exception interrupt control logic of the engine and generate 1 error exception interrupt output. Implement control operations for the error exception interrupt, including enabling, bitwise masking, clearing by channel, and updating the error exception interrupt status register. Interact with the configuration file heap regarding relevant control information and status information of the interrupt processing module. Interact with the engine functional module to obtain the control information and status information of the engine functional module for the queue.

[0096] The relevant information of a queue includes the following:

[0097] The tail pointer marker register written from the Function Kernel. The head pointer marker register written from the Function Kernel, which is not operated simultaneously with the tail pointer marker register. Feedback the remaining space information of the queue to the Function Kernel. Feedback the queue exception marker information to the Function Kernel. Interact with the engine functional module to obtain the system exception status information transferred by the engine functional module. Interact with the performance statistics module to generate or directly transfer key signals to the performance statistics module for statistics. The relevant information of a queue includes the following. The number of information elements written by the producer. The number of information elements read by the consumer. The number of writes by the producer, counting the update times of the tail pointer marker register. The number of reads by the consumer, counting the update times of the head pointer marker register. Interact with the debug tracing module to generate the information to be traced in a custom format and transfer it to the debug tracing module. The message header of the elements written by the producer. Interact with the signal monitoring module to send the signals to be monitored by the system to the signal monitoring module for processing. Queue non-empty signal. Queue non-full signal.

[0098] In an exemplary embodiment, the interface interaction device further includes a performance statistics module. Among them, the performance statistics module is passively connected to the modules in the engine device and is used to count the events generated by the modules in the engine device. The performance statistics module supports multiple event types, supports input of multiple events, supports trigger sources with multiple trigger times, supports counting statistics with start clock cycle configuration, and supports integration of multiple general modules.

[0099] Optionally, as Figure 6 shown, it is a schematic diagram of the hardware structure of the performance statistics module in this embodiment. The hardware interaction method of the performance statistics module QPA Kernel is as follows: The interaction between QPA Kernel and other modules inside the engine is mainly in a passive manner, that is, external information is input to QPA Kernel, and it performs processing and counting. The counting result is fully expressed inside the register. Function Kernel sends the value to be counted to QPA Kernel through the register interface. Function Kernel sends the event to be counted to QPA Kernel through a direct connection. Interrupt Kernel sends the relevant numerical information of the queue to be counted to QPA Kernel through the register interface. Interrupt Kernel sends the relevant events of the queue to be counted to QPA Kernel through a direct connection. QPA Kernel sends each QPCC counting overflow information to Interrupt Kernel through the register interface.

[0100] The Performance Statistics Module QPA Kernel can flexibly configure and manage various performance statistics requirements by integrating multiple Quick Performance Common Cell (QPCC) modules. Its function definitions include: Key event statistics: QPA Kernel can count key events inside the engine, such as the number of pulse edges, level periods, and multi-bit counts. These statistics help understand the engine's operating status and performance bottlenecks. Event input selection: Each QPCC module supports multi-channel event input selection and can receive event signals from different modules inside the engine or trigger statistics through external events. Count input selection: In addition to event signals, QPCC also supports the input of multiple counting sources for counting specific data streams or operation frequencies. External event trigger: QPA Kernel allows configuring multiple external events as statistical trigger sources, which means that statistics can be started or stopped by external signals, providing a more flexible performance monitoring solution. Clock cycle configuration: QPA Kernel supports configuring the start and end of count statistics according to a preset clock cycle, facilitating the accurate measurement of performance metrics within a specific time window. QPCC module control: Each QPCC module can independently configure its start and stop states, as well as the clearing operation of the internal counter, enabling QPA Kernel to dynamically adjust statistical requirements and meet performance monitoring in different scenarios. Trigger mode selection: The QPCC module supports two trigger modes: clock cycle trigger and external event trigger, providing richer control options for performance statistics and allowing optimization of statistical strategies according to specific application requirements. Count overflow handling: QPA Kernel also has the ability to handle count overflows, including overflow enabling, expression of overflow status, and status clearing mechanisms, ensuring the accuracy of statistics and the stability of the system.

[0101] In a specific embodiment, the configuration of the Performance Statistics Module (QPA Kernel) is as follows:

[0102] Implement statistics on key events inside the engine.

[0103] Supported event types for statistics: Number of pulse edge events. Level period events. Multi-bit count events.

[0104] Support multi-event selection for QPCC input: Event statistics input source, each QPCC supports 256 input event sources for selection. Count statistics input source, each QPCC supports 16 input counting sources for selection.

[0105] Support the selection of external event statistical trigger sources, with 32 trigger sources supported.

[0106] Support count statistics with start clock cycle configuration.

[0107] Supports the integration of 32 QPCC modules. The functions that each QPCC can perform include: starting and stopping the configurable QPCC unit; clearing the internal count of the configurable QPCC unit; the trigger mode of the QPCC unit can be selected, including clock cycle trigger and external event trigger.

[0108] Supports the handling of event statistical count overflow, including count overflow enabling, count overflow status expression, and status clearing, etc.

[0109] In an exemplary embodiment, the interface interaction device further includes a debug tracing module. The debug tracing module is connected to the modules in the engine device and is used to track key events and information in the engine device. The debug tracing module supports the integration of multiple tracing units and supports various types of tracing logs.

[0110] Optionally, as Figure 7 shown, is the schematic diagram of the hardware structure of the debug tracing module in this embodiment. The hardware interaction method of the debug tracing module includes: the Trace Kernel of the debug tracing module mainly realizes the information collection and tracking of the internal functional units of the engine, and then transmits the information out of the engine through the AXI Master interface. Currently, the AXI Master is not multiplexed with other functions and is dedicated to outputting information by the Trace Kernel. Receives the information that needs to be traced output by the Function Kernel through the register interface. Receives the information that needs to be traced output by the Interrupt Kernel through the register interface, mainly the information that needs to be traced for the queue function. Transmits the overflow status of the number of discarded logs inside to the Interrupt Kernel through the register interface. Interacts with the Data Master interface through the register interface to transmit the information that needs to be output outside the engine.

[0111] The functional definitions of the Trace Kernel include: Key event tracking: The Trace Kernel is responsible for real-time tracking of key events inside the engine, such as task execution, state changes, data flow operations, etc. This information is crucial for understanding the engine's behavior and diagnosing problems. Integrated tracking units: Multiple tracking units (TPCC) are integrated inside the Trace Kernel. Each unit can be independently configured and managed to track and record different types of events. This improves the system's tracking ability and flexibility. Log specifications: The Trace Kernel supports two log specifications: atomic logs and complex logs. Atomic logs only contain frame header and frame tail information for recording the occurrence of events; complex logs include frame header, payload, and frame tail information, providing more detailed event data and context. Log output control: At the log output end, the Trace Kernel provides two modes: secure output and discard output. The secure output mode ensures the complete recording of logs, but may cause delays in the execution of internal engine functions under external backpressure; the discard output mode allows random discarding of logs under backpressure to avoid affecting the execution of internal engine functions. The configurability of these two modes ensures the stable operation of the system under different load conditions. Log information classification: Each TPCC unit supports multiple log information classifications and can select filtered output through register configuration. This means that the Trace Kernel can select specific types of log information for output according to system requirements and priorities, such as filtered output in normal operating mode or when exceptions occur, to optimize storage resources and network bandwidth. Discarded log statistics and exception handling: The Trace Kernel supports counting the number of discarded logs for each TPCC unit. When a statistical overflow occurs, the Trace Kernel sends the number of the abnormal TPCC to the Interrupt Kernel, triggering an exception interrupt so that the system can respond in a timely manner and perform necessary error handling or log reconfiguration.

[0112] The functional design of the Trace Kernel reflects its importance and practicality in the software-hardware interaction interface. By integrating multiple tracking units, the Trace Kernel can provide comprehensive event tracking capabilities; by supporting different log specifications, it ensures the richness and efficiency of tracking information; the log output control and information classification mechanisms allow the system to dynamically adjust the tracking strategy according to actual needs to adapt to different scenarios.

[0113] In a specific embodiment, the configuration of the Trace Kernel includes: implementing the tracking of key events and information inside the engine. The Trace Kernel supports the integration of 32 tracking units.

[0114] The specifications of the trace information logs are divided into the following two categories: Atomic logs, with a fixed size of 4 bytes, containing only the frame header and frame tail information. Complex logs, with a fixed size of 16 bytes, including the frame header, payload, and frame tail information.

[0115] At the log output end, when the TPCC output is externally backpressure, two modes of secure output and discard output can be configured.

[0116] Secure output, a mode without log loss, which may cause a delay in the execution of internal engine functions at this time.

[0117] Discard output, the logs to be output are randomly discarded, without affecting the execution of the internal engine.

[0118] Each TPCC unit supports 16 types of log information classification, and the register can be configured to select filtered output.

[0119] The types of filtered output logs in the normal working mode can be configured.

[0120] When an exception occurs, the types of filtered output logs can be configured, and the filtered logs will be securely output.

[0121] Each TPCC supports the statistics of the number of discarded logs, and after the statistics overflow, the Trace Kernel sends the TPCC number with statistics overflow to the Interrupt Kernel to generate an exception interrupt.

[0122] In an exemplary embodiment, the interface interaction device further includes a status management module, wherein the status management module is connected to the module in the engine device and is used to perform the handshake between the status of the engine device and the status update request of the computer system.

[0123] Optionally, as Figure 8As shown, it is a schematic diagram of the hardware structure of the state management module in this embodiment. The hardware interaction methods of the State Monitor module include: The state management module is mainly used to receive state update requests sent by the master device. It does not force state updates but serves as a state update prompt message. It receives state update requests from the system master device for this engine or other engines controlled by this engine through registers. It feeds back the state of this engine or other engines controlled by this engine to the register through the register interface. It sends state update requests and feedback for other engines through the P Mst interface. It receives state update requests and feedback from the master device for this engine through the P Slv interface. It interacts with the Function Kernel for clock shutdown requests through a request-response handshake protocol. It interacts with the Function Kernel for reset requests through a request-response handshake protocol. It interacts with the Interrupt Kernel for clock shutdown requests through a request-response handshake protocol. It interacts with the Interrupt Kernel for reset requests through a request-response handshake protocol. It receives and feeds back the Interrupt Kernel error status through the register interface.

[0124] Optionally, the function definition of the State Monitor module includes: State update request: The State Monitor is responsible for handling and coordinating the handshake between the engine state and the external system state update requests. This includes the engine initiating state update requests to other engines, as well as receiving and responding to requests from other engines to update the state of this engine. Through this two-way request-response mechanism, the State Monitor ensures the orderliness and timeliness of state updates. Request-response method: The State Monitor supports two mutually exclusive request-response methods. One is to interact with state update requests through the P Mst (main channel) and P Slv (slave channel), and the other is to interact through register configuration and querying status registers. The choice of these two methods depends on the specific application scenario and system requirements to provide the most efficient and secure state management. State update type: The State Monitor implements multiple state update requests, including: Clock shutdown request: When the system requests to shut down the engine clock, the State Monitor is responsible for providing internal device time-limited feedback. If it times out, it will feedback a "rejected status" to ensure that the clock shutdown operation is completed within a safe time window. Reset request: When the system requests to reset the engine, the State Monitor is also responsible for providing time-limited feedback. If it times out, it will feedback a "rejected status" to ensure that the reset operation does not occur when the engine is performing critical tasks. Power-off request: When the system requests to turn off the engine power, the State Monitor also needs to provide internal device time-limited feedback. If it times out, it will feedback a "rejected status" to prevent the engine from being suddenly powered off during important operations. Task Flush request: The State Monitor supports Flush requests for the engine's custom task cache and queued tasks to empty the task queue inside the engine, which is particularly important when the engine restarts or its state changes. Register configuration update request: When the engine state is updated, the State Monitor receives register configuration update requests from the system or inside the engine to ensure that the configuration information is correctly applied within the specified time. State feedback and timeout handling: For the above state update requests, the State Monitor completes and feedbacks the state within the specified time. If it times out, it will feedback a "rejected status" to prevent system anomalies or data inconsistencies caused by untimely state updates. This mechanism ensures the reliability and security of state updates.

[0125] In the design of the software-hardware interaction interface, the role of the State Monitor module is to act as a bridge between the engine and the external system, ensuring the orderliness and security of state updates, which is crucial for improving the overall stability and response speed of the system.

[0126] In a specific embodiment, the configuration of the State Monitor module includes: implementing a handshake between the engine state and the external system state update request. This engine can receive requests from other engines to update its state. Implement update requests for the following aspects of the state: clock off request, timeout feedback "reject state". There is no need to request for clock on. Reset request, timeout feedback "reject state". There is no need to request for reset cancellation.

[0127] In an exemplary embodiment, the interface interaction device further includes a signal monitoring module. The signal monitoring module is used to output the signals in the engine device to the computer system. The signal monitoring module supports the frequency division output of the clock signal and the pulse stretching output of the high-level pulse signal.

[0128] Optionally, as Figure 9 shown, it is the schematic diagram of the hardware structure of the signal monitoring module in this embodiment. The hardware interaction method of the signal monitoring module Sig4Mon includes: Sig4Mon mainly supports the state observation of the internal signals of the engine during debugging, without requirements related to timing and performance. Each module sends the signals to be output to the Sig4Mon module through a direct connection line. Sig4Mon connects the signal to be output to the engine output pin through a direct connection line.

[0129] The function definition of the signal monitoring module Sig4Mon includes: selectively outputting internal signals outside the engine for observation, supporting multiple input signals, and these signals are grouped and selected for output. The characteristics requirements of each group of signals are as follows: including a clock signal, which can be frequency-divided after being input into the Sig4Mon module, or a normal level signal can be input. Including a pulse signal, which can be stretched after being input into the Sig4Mon module, or a normal level signal can be input. Including normal level signals. Support the frequency division output of the clock signal, the frequency division number can be configured, and when configured to 0, there is no frequency division. Support the pulse stretching output of the high-level pulse signal, the stretching can be configured, and when configured to 0, there is no stretching.

[0130] In a specific embodiment, the configuration of the signal monitoring module (Sig4Mon) includes: selectively outputting internal signals outside the engine for observation, supporting 512 input signals, and these signals are divided into 32 groups and selected for output, with 16 output signals in each group.

[0131] The characteristics requirements of each group of signals are as follows: Bit15 - Bit14: clock signal, which can be frequency-divided after being input into the Sig4Mon module, or a normal level signal can be input. Bit13 - Bit8: including a pulse signal, which can be stretched after being input into the Sig4Mon module, or a normal level signal can be input. Bit7 - Bit0: including normal level signals.

[0132] Supports clock signal frequency division output, with the division factor configurable, the maximum division factor being 32, and no division occurs when configured to 0.

[0133] Supports high-level pulse signal broadening output, with the broadening factor configurable, the maximum broadening multiple being 32, and no broadening occurs when configured to 0.

[0134] In an exemplary embodiment, the interface interaction device further includes a status update request interaction circuit. Among them, the status update request interaction circuit includes a primary interface and a standby interface, which are used to interact with multiple first functional components for status update requests.

[0135] Optionally, the primary interface in this embodiment can be P Mst, which is used for the status control interaction between the system and the engine, sending relevant status control information, and the key parameters and characteristics of the interface support macro definition, constant definition, and register configuration definition. The standby interface can be the P Slv interface, which is used for the status control interaction between the system and the engine, receiving relevant status control information, and the key parameters and characteristics of the interface support macro definition, constant definition, and register configuration definition.

[0136] In an exemplary embodiment, the interface interaction device further includes queue control logic. Among them, the queue control logic is used to process queue control information, status information, and system interaction information in the engine device, and interact with multiple first functional modules and the interrupt processing module in the interface interaction device, for realizing data interaction based on queue control information, status information, and system interaction information, as well as exception interrupt processing with the interrupt processing module.

[0137] Optionally, the queue control logic is a key part in the software and hardware interaction interface design for managing queue data structures. In complex engine devices, queues are widely used for data buffering, task scheduling, and resource management, etc. Therefore, the design of the queue control logic is crucial for ensuring the efficiency of data transmission, the order of task execution, and the fairness of resource allocation. The following is a detailed function description of the queue control logic in the interface interaction device:

[0138] Queue control information processing: The queue control logic is responsible for processing queue control information from multiple first functional modules (such as Function Kernel). These information may include queue creation, deletion, read and write operations, queue length, queue empty / full status, queue priority adjustment, etc. The queue control logic needs to be able to respond quickly and execute these control instructions to ensure the correct management and efficient operation of the queue.

[0139] Status Information Management: The queue control logic also needs to handle the status information of the queue, such as the current empty / full level of the queue, the data type in the queue, the error status of queue operations, etc. These status information are crucial for maintaining the healthy state of the queue and the system's monitoring of the queue. When the queue status is abnormal, the queue control logic needs to promptly feedback the status information to the relevant functional modules and the interrupt handling module, so that the system can immediately take measures, such as restarting the queue, adjusting the queue policy, or triggering an exception interrupt.

[0140] System Interaction Information Coordination: The queue control logic is also responsible for coordinating the interaction information between the engine device and the external system. This includes receiving data, commands, and status update requests sent by the external system, as well as sending information such as queue status, data availability, and error reports to the external system. The queue control logic needs to be able to accurately parse this interaction information and, based on the current status of the queue and control instructions, reasonably arrange the priorities of data transmission and command execution.

[0141] Exception Interrupt Handling: The queue control logic interacts closely with the interrupt handling module (Interrupt Kernel) to handle queue-related exception situations. When an error occurs in the queue, such as data overflow, null pointer exception, read / write conflict, etc., the queue control logic will generate an exception interrupt signal and send it to the interrupt handling module. After receiving the exception interrupt, the interrupt handling module will perform corresponding operations according to the preset interrupt handling strategy, such as clearing the error status, restarting the queue, recording the error log, etc., to ensure the stability of the system and the integrity of the data.

[0142] Data Interaction Management: The queue control logic is responsible for managing the multiplexed data interaction based on the queue. This includes reasonably scheduling the data transmission in the queue according to the queue control information and status information to ensure the correct order and lossless transmission of the data. During the data interaction process, the queue control logic also needs to work together with multiple first functional modules and the interrupt handling module to handle exception situations and interrupt events in data transmission.

[0143] Macro Definition Configuration and Status Feedback: The queue control logic supports macro definition configuration, allowing flexible definition of queue parameters and characteristics during the design phase. At the same time, the queue control logic can feedback the real-time status information of the queue to the configuration file heap (Register File&SRAM), so that the system can monitor the queue status in real time and perform necessary status adjustments and fault diagnosis.

[0144] In an exemplary embodiment, the interface interaction device further includes a performance statistics module, wherein the performance statistics module is integrated in the configuration file heap and is used to count the events in the configuration file heap and support the handling of count overflow.

[0145] Optionally, the performance statistics module QPCC is integrated into the configuration file heap to count events in the configuration file heap and support handling of count overflow.

[0146] Optionally, Quick Performance Common Cell (QPCC) in the performance statistics module QPA Kernel is integrated into the configuration file heap (Register File & SRAM). The integration of the QPCC module into the configuration file heap not only simplifies the hardware design but also improves the flexibility and efficiency of the statistics function. The following is the process of integrating QPCC into the configuration file heap:

[0147] Startup and configuration of event statistics: QPCC is used to count specific events defined in the configuration file heap. These events can be the number of accesses to hardware interfaces, data transfer rates, queue operation frequencies, etc., which are directly related to the running state and performance of the engine. The startup and stop of QPCC, as well as the configuration of statistical parameters, are all performed through registers in the configuration file heap, allowing dynamic adjustment of statistical tasks at the software level according to needs.

[0148] Handling of count overflow: QPCC also has the ability to handle count overflow, which is a common problem in performance statistics, especially in high-load or long-running scenarios. When the counter reaches the maximum value, QPCC stores the count overflow status in the status register and may generate an interrupt signal to notify the function module (Function Kernel) or the interrupt handling module (Interrupt Kernel) to perform overflow handling. Overflow handling may include resetting the counter, recording error logs, and adjusting statistical thresholds to ensure the accuracy and continuity of statistics.

[0149] Reading and application of statistical results: The statistical results of QPCC are stored in specific registers in the configuration file heap. Software can obtain statistical information by reading these registers for performance monitoring, fault diagnosis, or system optimization. In addition, the statistical results may also be used for further analysis by the performance statistics module (QPA Kernel) or interaction with the debug trace module (Trace Kernel) to provide deeper system insights.

[0150] In an exemplary embodiment, the interface interaction device further includes a debug trace module, where the debug trace module is integrated into the configuration file heap to trace information in the configuration file heap and support control of log output.

[0151] Optionally, the Trace Kernel is integrated into the Register File & SRAM to closely couple the engine's running state with the generation of debugging information, enabling in-depth analysis of system behavior and fault location. The integration of the Trace Kernel module into the Register File & SRAM allows it to directly access and track key information related to engine configuration, providing real-time trace logs. The following is the integration process of the Trace Kernel in the Register File & SRAM:

[0152] Startup and configuration of information tracing: The Trace Kernel is used to trace key information in the Register File & SRAM, including but not limited to changes in control signals, records of data read and write operations, capture of abnormal states, etc. Software can start, stop, or adjust the tracing function of the Trace Kernel through specific registers in the Register File & SRAM, which includes selecting the types of events to be traced, setting the format of log output, and filtering conditions, etc.

[0153] Log output control: The Trace Kernel supports the control of trace log output to adapt to different debugging requirements and system resource limitations. This includes real-time output, buffered output, filtered output, and the selection of secure output / discard output modes of the logs. Software can dynamically adjust the log output strategy according to the current debugging scenario or system load to balance the relationship between the detail level of debugging information and system performance.

[0154] Capture and handling of exception logs: The Trace Kernel can capture and record abnormal states during the engine's operation, such as incorrect register access, data transfer failures, queue operation exceptions, etc. These exception logs are crucial for the diagnosis and recovery of system faults. The Trace Kernel also needs to support the secure output of exception logs, ensuring that key exception information can be completely recorded and transmitted even under high system load or resource constraints.

[0155] Storage and retrieval of tracing information: The trace logs generated by the Trace Kernel can be stored in a specified area in the Register File & SRAM for subsequent analysis and retrieval. Software can obtain tracing information by reading the log registers in the Register File & SRAM for offline data analysis or fault troubleshooting.

[0156] By integrating the Trace Kernel into the configuration file heap, the following advantages can be achieved: Real-time information acquisition: The Trace Kernel directly accesses the data in the configuration file heap, enabling real-time tracking of the engine's operating status and software operations, and providing immediate debugging feedback. Efficient resource utilization: Integrated into the configuration file heap, the Trace Kernel can utilize existing hardware resources for information tracking, avoiding the overhead of additional hardware and improving resource utilization efficiency. Dynamic configuration ability: The tracing function of the Trace Kernel can be dynamically configured through the registers in the configuration file heap, enabling the software to flexibly control the start, stop, and parameter adjustment of tracing to meet different debugging requirements. Exception capture and handling: The Trace Kernel can capture and record the abnormal status of the engine. Through secure log output control, it ensures the reliable recording and transmission of exception information, providing key data for system fault diagnosis.

[0157] In an exemplary embodiment, the interaction interface includes at least one of the following: an interrupt interface, a register interface, a memory access interface, a queue interface, and a status handshake interface.

[0158] Optionally, the interrupt interface Interrupt includes interrupt signals and interrupt control, status registers, etc. in a wire-connected manner. The interrupt interface is mainly used to send interrupt signals to the software when specific events occur in the hardware device (such as data transfer completion, error detection, external event occurrence, etc.) to attract the attention of the software and take corresponding actions. Interrupt signals in a wire-connected manner: These are direct connection signals between the hardware module and the interrupt controller for transmitting interrupt requests. The interrupt signal can be edge-triggered (rising edge or falling edge) or level-triggered (continuous high level or low level). Interrupt control, status registers: These registers are used to control operations such as enabling, masking, and clearing interrupts and store interrupt status information. The software can manage interrupts by reading and writing these registers, such as enabling specific types of interrupts, querying the interrupt status, and clearing the interrupt flag. Register / Memory access Register / Memory interface: This interface allows the software to directly access the registers and memory in the hardware for configuring hardware parameters, reading hardware status, storing, and retrieving data, etc. In hardware description languages, the register / memory access interface usually follows certain communication protocols, such as AMBA AHB / AHB-Lite or AMBA AXI, etc.

[0159] The register interface is used to read and write the registers in the hardware. These registers can be control registers, status registers, configuration registers, etc., for parameter transfer and status monitoring between the software and the hardware.

[0160] The memory interface is used to access memories in hardware, such as SRAM, DRAM, Flash, etc., for long-term data storage and large-capacity caching.

[0161] The Queue interface is used to manage and control the queue data structure in hardware devices, including enqueueing and dequeueing operations of data, monitoring of queue status (such as empty or full status of the queue), queue depth configuration, etc. The queue interface is particularly important when dealing with high-load, real-time data transmission or task scheduling.

[0162] The queue control and status logic is used to process the control signals of the queue, such as enqueue enable, dequeue enable, and read / write operations of the queue. It also includes the status monitoring logic of the queue, such as detecting whether the queue is empty or full.

[0163] The queue storage space is the actual hardware space for storing queue data, usually composed of a set of registers or memories, supporting first-in-first-out (FIFO), last-in-first-out (LIFO), or other queue organization methods.

[0164] The State Handshake interface is a communication mechanism used for the exchange of status information between hardware devices and software to ensure synchronization and coordination between the two. It usually includes interaction processes such as requests, responses, and status confirmations.

[0165] Requests and responses: The software sends status queries or control commands to the hardware through request signals, and the hardware feeds back to the software through response signals according to the current status.

[0166] Status interaction: The hardware device reports its current working status, such as running, pausing, malfunctioning, etc., to the software through status signals, and the software can make corresponding decisions based on this.

[0167] For example, the peripheral interface is set as follows: an AXI Master interface is implemented for sending data commands, with a data bit width of 32 bits and an address bit width of 64 bits, and it is compatible with the AMBA AXI4 protocol. An AXI Slave interface is implemented for receiving data, with a data bit width of 32 bits and is compatible with the AMBA AXI4 protocol. An AHB Slave interface is implemented for receiving control information, with a data bit width of 32 bits and is compatible with the AMBA AHB protocol. A PChannel Slave interface is implemented for receiving the system's control of the engine status and is compatible with the AMBA PChannel protocol. A Sig4Mon Port interface is implemented, with an output bit width of 16 bits. An exception interrupt Int interface is implemented, with an output bit width of 1 bit and active high. A function interrupt Int interface is implemented, with an output bit width of 8 bits and active high. The P Mst interface is not implemented. The Func Inf interface is not implemented. The SelfDefine Input Port interface is not implemented.

[0168] In the method embodiments provided in the embodiments of the present application, they can be executed in a server device or a similar computing device. Taking running on a server device as an example, Figure 10 is a hardware structure block diagram of a server device for a data interaction method according to an embodiment of the present application. As Figure 10 shown, the server device may include one or more ( Figure 10 only one is shown in the figure) processors 1002 (the processor 1002 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 1004 for storing data. Among them, the above server device may further include a transmission device 1006 for communication functions and an input / output device 1008. Those of ordinary skill in the art can understand that Figure 10 the structure shown is only schematic and does not limit the structure of the above server device. For example, the server device may further include more or fewer components than Figure 10 shown in the figure, or have a different configuration from Figure 10 shown in the figure.

[0169] The memory 1004 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the data interaction method in the embodiments of the present application. The processor 1002 executes various functional applications and data processing by running the computer program stored in the memory 1004, that is, the above-mentioned method is implemented. The memory 1004 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 1004 may further include a memory remotely provided with respect to the processor 1002, and these remote memories can be connected to the server device through a network. Examples of the above network include but are not limited to the Internet, enterprise intranet, local area network, mobile communication network, and combinations thereof.

[0170] The transmission device 1006 is used to receive or send data via a network. Specific examples of the above network may include a wireless network provided by a communication provider of the server device. In one instance, the transmission device 1006 includes a network adapter (Network Interface Controller, abbreviated as NIC), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission device 1006 may be a radio frequency (Radio Frequency, abbreviated as RF) module, which is used to communicate with the Internet wirelessly.

[0171] In this embodiment, a data interaction method is provided. Figure 11 is a flowchart of the data interaction method according to the embodiments of the present application, as Figure 11 shown, and the process includes the following steps:

[0172] Step S1102, when the interface parameters and interface attributes of the interaction interface are configured by a macro definition configuration component, a data command is transmitted to a functional component in the engine device through the interaction interface, where the interface parameters and the interface attributes are both used to configure the ability of the interaction interface to meet the communication requirements between the engine device and the control device in the computer system;

[0173] Step S1104, the functional component responds to the data command to process the data in the data command;

[0174] Step S1106, the processing result is sent to the control device through the interaction interface; wherein, the interaction interface and the functional component are both deployed in an interface interaction device, and the interface interaction device is deployed in the engine device.

[0175] Through the above steps, since the parameter and attribute configuration of the interaction interface between the engine device and the computer system is configured through macro definition, it is ensured that the interface can meet the communication requirements of both parties. The setting of multiple first functional components and the bus interface functional component not only improves the efficiency of data processing, but also realizes the accurate storage of data and the reasonable distribution of results. Therefore, the problem that the interaction framework between software and hardware in the related art affects the speed and accuracy of data interaction can be solved.

[0176] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such an understanding, the technical solution of the present application, in essence, or the part that makes a contribution to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions for causing a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present application.

[0177] It should be noted that the above-mentioned various modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited thereto: the above-mentioned modules are all located in the same processor; or, the above-mentioned various modules are respectively located in different processors in any combination form.

[0178] The embodiment of the present application also provides a computer-readable storage medium, in which a computer program is stored. Wherein, the computer program is set to execute the steps in any one of the above method embodiments when running.

[0179] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drive, read-only memory (abbreviated as ROM), random access memory (abbreviated as RAM), mobile hard disk, magnetic disk or optical disk and other various media that can store computer programs.

[0180] The embodiment of the present application also provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is set to run the computer program to execute the steps in any one of the above method embodiments.

[0181] In an exemplary embodiment, the above electronic device may further include a transmission device and an input / output device. Wherein, the transmission device is connected to the above processor, and the input / output device is connected to the above processor.

[0182] An embodiment of the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0183] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0184] An embodiment of the present application further provides a computer program. The computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any one of the above method embodiments.

[0185] Specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be repeated here.

[0186] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present application can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order from here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to implement. In this way, the present application is not limited to any specific combination of hardware and software.

[0187] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the principle of the present application shall be included in the protection scope of the present application.

Claims

1. An interface interaction device, characterized in that: The interface interaction device is deployed in an engine device in a computer system, and includes: A macro definition configuration component, used to configure interface parameters and interface properties of an interactive interface connected between the engine device and the computer system, wherein the interface parameters and the interface properties are used to configure the interactive interface to have the ability to transmit communication requirements between the engine device and the control device in the computer system; A plurality of first functional components, configured to perform processing operations on data transmitted by the interactive interface; The bus interface functional component is used to perform address differentiation operation on the data transmitted by the interactive interface so as to store the data in a storage device and allocate storage space for the processing results obtained by the processing operations performed by the multiple functional components.

2. The device according to claim 1, characterized in that The plurality of first functional components include: a data master control module, a data slave control module and a control slave control module, wherein: The data master control module supports multiple groups of data master control interfaces in the interactive interface and is used to send data generated between the computer system and the engine device; The data slave control module supports multiple groups of data slave control interfaces in the interactive interface and is used to receive data generated between the computer system and the engine device; The control slave module is used to receive configuration information of the computer system, wherein the configuration information is used to configure the functions of the functional components in the engine device.

3. The device according to claim 1, characterized in that The interface interaction device also includes a configuration file stack, wherein: The configuration file stack is connected to a plurality of the first functional components, and is used to control the functional interaction, information interaction, and status interaction of the engine device based on the processing operations of the plurality of the first functional components.

4. The device according to claim 3, characterized in that The configuration file stack includes: a function register file stack, an interrupt register file stack, a performance statistics register file stack, a trace debug register file stack, and a storage module, wherein: The function register file stack includes registers for controlling interface features, interface functions and interface status feedback of a plurality of the first function components; The interrupt register file stack includes registers for controlling abnormal interrupts and abnormal status feedback of a plurality of the first functional components; The performance statistics register file stack includes registers for controlling performance statistics and performance status feedback in the engine device; The trace and debug register file stack includes registers for controlling the trace and debug of the engine device and debug status feedback; The storage module includes the storage space of the engine device.

5. The device according to claim 4, characterized in that The computer system performs read and write operations on the configuration file stack through the control slave modules in the plurality of the first functional components and the bus interface functional component.

6. The device according to claim 4, characterized in that The configuration file stack is connected to the bus interface functional component via a static random access memory interface; The configuration file stack and the plurality of the first functional components exchange data via a first direct line.

7. The device according to claim 4, characterized in that When the interrupt processing module in the interface interaction device writes the interrupt error information into the interrupt register file stack, the interrupt register file stack and the interrupt processing module interact with each other through the register interface timing to write the interrupt error information serially; or, When the configuration file stack operation fails and the configuration file stack writes the interrupt error information to the interrupt processing module in the interface interaction device, the interrupt register file stack and the interrupt processing module interact with each other through the register interface timing to serially write information.

8. The device according to claim 5, characterized in that The storage module is connected to the engine function module in the interface interaction device via a memory interface. The data interaction between the storage module and the engine function module includes read and write operations. The engine function module and the control slave module perform arbitration operations on the access to the storage module.

9. The device according to claim 3, characterized in that The interface interaction device also includes an engine function module, wherein: The engine function module is connected to the first function components via a first register interface and is connected to the configuration file stack via a second direct line. The engine function module is used to perform data exchange with the first function components and the configuration file stack.

10. The device according to claim 1, characterized in that The interface interaction device also includes an interrupt processing module, wherein: The interrupt processing module is connected to the module in the engine device through the second register interface, and is used to receive an interrupt request sent by the module in the engine device, and perform interrupt processing and routing on the interrupt request.

11. The device according to claim 1, characterized in that The interface interaction device also includes a performance statistics module, wherein: The performance statistics module is passively connected to the modules in the engine device, and is used to count the events generated by the modules in the engine device, wherein the performance statistics module supports multiple event types, supports the input of multiple events, supports trigger sources with multiple trigger times, supports counting statistics configured for the start clock cycle, and supports the integration of multiple general modules.

12. The device according to claim 1, characterized in that The interface interaction device also includes a debugging and tracking module, wherein: The debugging and tracing module is connected to the module in the engine device and is used to track key events and information in the engine device. The debugging and tracing module supports integration of multiple tracing units and supports multiple types of tracing logs.

13. The device according to claim 1, characterized in that The interface interaction device also includes a state management module, wherein: The state management module is connected to the module in the engine device and is used to perform a handshake between the state of the engine device and the state update request of the computer system.

14. The device according to claim 1, characterized in that The interface interaction device also includes a signal monitoring module, wherein: The signal monitoring module is used to output the signal in the engine device to the computer system, wherein the signal monitoring module supports the frequency division output of the clock signal and supports the widening output of the high-level pulse signal.

15. The device according to claim 1, characterized in that The interface interaction device also includes a status update request interaction circuit, wherein: The status update request interaction circuit includes a main interface and a backup interface, which are used to interact with multiple first functional components in terms of status update requests.

16. The device according to claim 1, characterized in that The interface interaction device also includes queue control logic, wherein: The queue control logic is used to process the queue control information, status information and system interaction information in the engine device, and interact with the multiple first functional modules and the interrupt processing module in the interface interaction device to realize data interaction based on the queue control information, the status information and the system interaction information, as well as abnormal interrupt processing between the interrupt processing module.

17. The device according to claim 3, characterized in that The interface interaction device also includes a performance statistics module, wherein: The performance statistics module is integrated in the configuration file stack, and is used to count events in the configuration file stack and support the processing of count overflow.

18. The device according to claim 3, characterized in that The interface interaction device also includes a debugging and tracking module, wherein: The debugging and tracing module is integrated in the configuration file stack, and is used to trace the information in the configuration file stack and support log output control.

19. The device according to claim 1, characterized in that The interactive interface includes at least one of the following: an interrupt interface, a register interface, a memory access interface, a queue interface, and a status handshake interface.

20. A data interaction method, characterized in that: include: In the case where the interface parameters and interface properties of the interactive interface are configured through the macro definition configuration component, the data command is transmitted to the functional component in the engine device through the interactive interface, wherein the interface parameters and the interface properties are used to configure the interactive interface to have the ability to transmit the communication requirements between the engine device and the control device in the computer system; Responding to the data command through the functional component to process the data in the data command; Sending the processing result to the control device through the interactive interface; Wherein, the interactive interface and the functional component are both deployed in an interface interactive device, and the interface interactive device is deployed in the engine device.

21. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in claim 20 when executed by a processor.

22. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in claim 20 are implemented.

Images