Firmware running method and device, and electronic device

Abstract

The present disclosure provides a firmware running method and device and an electronic device, comprising: compiling a to-be-verified firmware into a local executable program, and running firmware program logic corresponding to the local executable program by a target lightweight emulation model in a local execution environment; wherein the target lightweight emulation model omits an instruction-level processing pipeline, is connected with an on-chip interconnection network through a bus transaction output interface, and is configured with a memory access programming interface, and the target lightweight emulation model and a complete instruction set emulator model have the same bus interface configuration information; when the firmware program logic calls the memory access programming interface, encapsulating a memory access request generated by the firmware program logic into a bus memory access transaction; wherein the bus memory access transaction is sent to the on-chip interconnection network through the bus transaction output interface to access a target device; thereby completing sending the bus memory access transaction and accessing the target device without executing each instruction in the instruction-level processing pipeline, and shortening the emulation verification period.

Description

Technical Field

[0001] This disclosure relates to the field of chip technology, and in particular to a firmware running method and apparatus, and an electronic device. Background Technology

[0002] In System-on-Chip (SoC) emulation platforms, a complete instruction set emulator model is typically used to verify firmware program logic. This model executes the firmware program logic line by line through an instruction-level processing pipeline and generates bus memory access transactions.

[0003] In related technologies, when verifying firmware using a complete instruction set simulator model, the firmware needs to be compiled to generate an image and loaded into the model, and the simulation time needs to be advanced according to the instructions. However, when the firmware is modified, the instruction-level processing pipeline operation needs to be repeated, resulting in a long verification cycle. Summary of the Invention

[0004] This disclosure provides a firmware running method, apparatus, and electronic device to solve the problem in related technologies where repeated instruction-level processing pipeline operations are required when firmware is modified, resulting in a long verification cycle.

[0005] According to a first aspect of this disclosure, a firmware running method is provided, comprising: The firmware to be verified is compiled into a native executable program, and the firmware program logic corresponding to the native executable program is run by the target lightweight simulation model in the local execution environment. The target lightweight simulation model omits the instruction-level processing pipeline, connects to the on-chip interconnect network through the bus transaction output interface, and is configured with a memory access programming interface. The target lightweight simulation model is configured to have the same bus interface configuration information as the full instruction set emulator model, so that the target lightweight simulation model can run in place of the full instruction set emulator model. When the firmware program logic calls the memory access programming interface, the memory access request generated by the firmware program logic is encapsulated into a bus memory access transaction; wherein, the bus memory access transaction is sent to the on-chip interconnect network via the bus transaction output interface to access the target device.

[0006] In some embodiments of this disclosure, after compiling the firmware to be verified into a native executable program, the method further includes: Write operations to preset registers in the target lightweight simulation model are detected through the on-chip interconnect network; When the data of the write operation matches the preset trigger identifier, the target lightweight simulation model is triggered to start running the firmware program logic.

[0007] In some embodiments of this disclosure, the method further includes: During the execution of the firmware program logic by the target lightweight simulation model, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface; wherein, the simulation time slice is a fixed time length, so that the target lightweight simulation model does not need to accumulate simulation time according to each instruction.

[0008] In some embodiments of this disclosure, compiling the firmware to be verified into a native executable program includes: The firmware to be verified is compiled and linked with the simulation library to generate the native executable program. During the compilation and linking process, the simulation library provides symbolic stubs corresponding to the memory access programming interface, and the firmware to be verified provides symbolic definitions corresponding to the symbolic stubs. The symbolic definitions override the symbolic stubs, binding the firmware to be verified's calls to the memory access programming interface to the internal functions of the target lightweight simulation model.

[0009] In some embodiments of this disclosure, the method further includes: During the execution of the firmware program logic in the target lightweight simulation model, when communication with the host-side control logic is required, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface, so that the simulation thread corresponding to the host-side control logic can obtain execution permission; wherein, the target lightweight simulation model runs the firmware program logic and the host-side control logic through dual simulation threads respectively.

[0010] In some embodiments of this disclosure, encapsulating the memory access request generated by the firmware program logic into a bus memory access transaction includes: Based on the transaction-level modeling standard, the memory access request is encapsulated as the bus memory access transaction, and a route extension identifier is added to the bus memory access transaction. The bus memory access transaction is sent in a single blocking transaction transmission mode. The route extension identifier indicates that the target lightweight simulation model is the origin of this memory access request.

[0011] In some embodiments of this disclosure, the target lightweight simulation model includes a memory access unit, a computing array unit, a memory unit, and a peripheral interface unit. The memory access unit, the computing array unit, the memory unit, and the peripheral interface unit are all connected to the bus transaction output interface and are uniformly routed to the on-chip interconnect network through the bus transaction output interface.

[0012] In some embodiments of this disclosure, the method further includes: When in the first simulation mode, the complete instruction set simulator model is used for operation; When in the second simulation mode, the target lightweight simulation model is used for operation.

[0013] According to a second aspect of this disclosure, a firmware running apparatus is provided, comprising: The compilation unit is used to compile the firmware to be verified into a native executable program. The execution unit is used to run the firmware program logic corresponding to the local executable program in the local execution environment by the target lightweight simulation model; wherein, the target lightweight simulation model omits the instruction-level processing pipeline, is connected to the on-chip interconnect network through a bus transaction output interface, and is configured with a memory access programming interface, and is configured to have the same bus interface configuration information as the full instruction set emulator model, so that the target lightweight simulation model can run in place of the full instruction set emulator model; An encapsulation unit is used to encapsulate the memory access request generated by the firmware program logic into a bus memory access transaction when the firmware program logic calls the memory access programming interface; wherein the bus memory access transaction is sent to the on-chip interconnect network via the bus transaction output interface to access the target device.

[0014] In some embodiments of this disclosure, the apparatus is further configured to: After the compilation unit compiles the firmware to be verified into a local executable program, the write operation to the preset register in the target lightweight simulation model is detected through the on-chip interconnect network. When the data of the write operation matches the preset trigger identifier, the target lightweight simulation model is triggered to start running the firmware program logic.

[0015] In some embodiments of this disclosure, the apparatus is further configured to: During the execution of the firmware program logic by the target lightweight simulation model, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface; wherein, the simulation time slice is a fixed time length, so that the target lightweight simulation model does not need to accumulate simulation time according to each instruction.

[0016] In some embodiments of this disclosure, the compilation unit is further configured to: The firmware to be verified is compiled and linked with the simulation library to generate the native executable program. During the compilation and linking process, the simulation library provides symbolic stubs corresponding to the memory access programming interface, and the firmware to be verified provides symbolic definitions corresponding to the symbolic stubs. The symbolic definitions override the symbolic stubs, binding the firmware to be verified's calls to the memory access programming interface to the internal functions of the target lightweight simulation model.

[0017] In some embodiments of this disclosure, the apparatus is further configured to: During the execution of the firmware program logic in the target lightweight simulation model, when communication with the host-side control logic is required, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface, so that the simulation thread corresponding to the host-side control logic can obtain execution permission; wherein, the target lightweight simulation model runs the firmware program logic and the host-side control logic through dual simulation threads respectively.

[0018] In some embodiments of this disclosure, the packaging unit is further configured to: Based on the transaction-level modeling standard, the memory access request is encapsulated as the bus memory access transaction, and a route extension identifier is added to the bus memory access transaction. The bus memory access transaction is sent in a single blocking transaction transmission mode. The route extension identifier indicates that the target lightweight simulation model is the origin of this memory access request.

[0019] In some embodiments of this disclosure, the target lightweight simulation model includes a memory access unit, a computing array unit, a memory unit, and a peripheral interface unit. The memory access unit, the computing array unit, the memory unit, and the peripheral interface unit are all connected to the bus transaction output interface and are uniformly routed to the on-chip interconnect network through the bus transaction output interface.

[0020] In some embodiments of this disclosure, the apparatus is further configured to: When in the first simulation mode, the complete instruction set simulator model is used for operation; When in the second simulation mode, the target lightweight simulation model is used for operation.

[0021] According to a third aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect of the present disclosure.

[0022] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect of the present disclosure.

[0023] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method described in the first aspect of the preceding embodiments.

[0024] The firmware running method, apparatus, and electronic device disclosed herein include: compiling the firmware to be verified into a native executable program, and having a target lightweight simulation model run the firmware program logic corresponding to the native executable program in a local execution environment; wherein, the target lightweight simulation model omits the instruction-level processing pipeline, connects to the on-chip interconnect network through a bus transaction output interface, and is configured with a memory access programming interface, and is configured to have the same bus interface configuration information as the full instruction set simulator model, so that the target lightweight simulation model can run in place of the full instruction set simulator model; when the firmware program logic calls the memory access programming interface, the memory access request generated by the firmware program logic is encapsulated into a bus memory access transaction; wherein, the bus memory access transaction is sent to the on-chip interconnect network through the bus transaction output interface to access the target device; thereby, sending the bus memory access transaction and accessing the target device can be completed without executing the instruction-level processing pipeline step by step, shortening the simulation verification cycle.

[0025] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0026] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a firmware operation method provided in an embodiment of the present disclosure; Figure 2 A schematic diagram of the architecture of a target lightweight simulation model provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram illustrating a code writing and model deployment process provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of the execution flow of a firmware running method provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of a simulated thread scheduling process provided in an embodiment of this disclosure; Figure 6This is a schematic diagram of a memory access path provided in an embodiment of the present disclosure; Figure 7 This is a schematic diagram of an implementation hierarchy provided by an embodiment of the present disclosure; Figure 8 This is a schematic diagram of a memory access call process provided in an embodiment of the present disclosure; Figure 9 This is a schematic diagram of the structure of a firmware running device provided in an embodiment of the present disclosure; Figure 10 A schematic block diagram of an example electronic device provided for embodiments of this disclosure. Detailed Implementation

[0027] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0028] The firmware operation method, apparatus, and electronic device of this disclosure are described below with reference to the accompanying drawings.

[0029] Figure 1 This is a schematic flowchart of a firmware operation method provided in an embodiment of the present disclosure.

[0030] like Figure 1 As shown, the method includes the following steps: Step 101: Compile the firmware to be verified into a local executable program, and run the firmware program logic corresponding to the local executable program in the local execution environment by the target lightweight simulation model; wherein, the target lightweight simulation model omits the instruction-level processing pipeline, connects to the on-chip interconnect network through the bus transaction output interface, and is configured with a memory access programming interface, and is configured to have the same bus interface configuration information as the full instruction set emulator model, so that the target lightweight simulation model can replace the full instruction set emulator model in running.

[0031] In some embodiments, the target lightweight simulation model is a processor functional model deployed on a Transaction Level Modeling (TLM) simulation platform; the local execution environment refers to the host operating system and its processor runtime environment running the TLM simulation platform; the local executable program refers to application code that can be directly executed under the host operating system; the target lightweight simulation model omits the instruction-level processing pipeline, meaning that when running the firmware to be verified, the target lightweight simulation model does not perform instruction-level simulation operations such as instruction fetching, decoding, and execution, but instead allows the firmware to be verified to run directly on the host machine in the form of a local executable program; the memory access programming interface is a standard application programming interface provided by the target lightweight simulation model to the firmware to be verified, and the firmware to be verified initiates a memory access request by calling the memory access programming interface; the bus transaction output interface is a dedicated interface for the target lightweight simulation model to send data to the on-chip interconnect network, and the target lightweight simulation model interacts with the on-chip interconnect network through the bus transaction output interface. The bus interface configuration information includes the physical address mapping of the bus transaction output interface in the target lightweight simulation model and the peripheral topology connection relationship mounted on the on-chip interconnect. Since the target lightweight simulation model and the full instruction set emulator model use the same address space allocation and bus transaction conversion rules, when the target lightweight simulation model is configured to replace the full instruction set emulator model, its interaction with the on-chip interconnect through the bus transaction output interface is logically equivalent to that of the full instruction set emulator model. This means that the target device mounted on the on-chip interconnect does not need to be aware of whether the target lightweight simulation model or the full instruction set emulator model is currently running.

[0032] In this way, the firmware to be verified no longer needs to be executed instruction by instruction through an instruction set emulator. Instead, it directly utilizes the host processor's computing resources to execute native executable programs, thus avoiding the simulation time consumed by the instruction-level processing pipeline. Furthermore, by directly calling the memory access programming interface to encapsulate bus memory access transactions, bus access effects can be generated directly, skipping the instruction-level processing. Simultaneously, since the target lightweight simulation model and the full instruction set emulator model have the same bus interface configuration information, when the target lightweight simulation model is used in place of the full instruction set emulator model in the simulation platform, there is no need to adjust the physical address mapping of the on-chip interconnect network and the peripheral topology connections. This allows for seamless replacement between simulation models while maintaining consistency in bus interaction logic.

[0033] Step 102: When the firmware program logic calls the memory access programming interface, the memory access request generated by the firmware program logic is encapsulated into a bus memory access transaction; wherein, the bus memory access transaction is sent to the on-chip interconnect network through the bus transaction output interface to access the target device.

[0034] In some embodiments, firmware program logic refers to the code logic executed by the firmware to be verified during operation; a memory access request is a data request generated by the firmware program logic when it needs to read or write to the target device through the on-chip interconnect network, according to the calling specification of the memory access programming interface; after receiving the memory access request, the target lightweight simulation model packages the address information and read / write instructions contained in the memory access request into a bus memory access transaction according to the standard format of transaction-level modeling (TLM); the bus memory access transaction contains the address information and read / write instructions of the target device; the target lightweight simulation model sends the bus memory access transaction to the bus transaction output interface, which transmits it to the on-chip interconnect network; after receiving the bus memory access transaction, the on-chip interconnect network routes the bus memory access transaction to the target device according to the address information in the bus memory access transaction; the target device is a peripheral unit or storage unit mounted on the on-chip interconnect network.

[0035] In this way, the memory access requests generated by the firmware program logic during operation can be directly encapsulated into bus memory access transactions by the target lightweight simulation model and sent to the on-chip interconnect network by calling the memory access programming interface. Thus, actual bus access to the target device can still be performed without skipping the instruction-level processing pipeline.

[0036] In summary, the firmware execution method provided in this disclosure includes: compiling the firmware to be verified into a native executable program, and having the target lightweight simulation model run the firmware program logic corresponding to the native executable program in a local execution environment; wherein, the target lightweight simulation model omits the instruction-level processing pipeline, connects to the on-chip interconnect network through a bus transaction output interface, and is configured with a memory access programming interface, and is configured to have the same bus interface configuration information as the full instruction set simulator model, so that the target lightweight simulation model can run in place of the full instruction set simulator model; when the firmware program logic calls the memory access programming interface, the memory access request generated by the firmware program logic is encapsulated into a bus memory access transaction; wherein, the bus memory access transaction is sent to the on-chip interconnect network through the bus transaction output interface to access the target device; thereby, sending the bus memory access transaction and accessing the target device can be completed without executing the instruction-level processing pipeline step by step, shortening the simulation verification cycle.

[0037] Optionally, based on any of the above embodiments or optional methods, the present disclosure embodiments may also employ the following method, but not limited thereto: the method includes: detecting a write operation to a preset register in the target lightweight simulation model through the on-chip interconnect network; when the data of the write operation matches a preset trigger identifier, triggering the target lightweight simulation model to start running the firmware program logic.

[0038] In some embodiments, the target lightweight simulation model is provided with a preset register, which is used to receive write operations from the on-chip interconnect network. When an external control device or host-side control logic needs to control the startup of the target lightweight simulation model, data corresponding to a preset trigger identifier is written to the preset register through the on-chip interconnect network. The target lightweight simulation model detects the written data in the preset register in real time. When the written data is detected to match the preset trigger identifier, the target lightweight simulation model switches from standby state to running state and begins to execute firmware program logic.

[0039] In this way, the startup process of the target lightweight simulation model does not require separate configuration of reset vector or image load instructions. Instead, the firmware program logic can be triggered to start running through the write operation of the on-chip interconnect network, so that the startup process is consistent with the hardware control bus path.

[0040] Optionally, based on any of the above embodiments or optional methods, the present disclosure embodiments may also employ the following method, but not limited thereto: the method includes: during the execution of the firmware program logic by the target lightweight simulation model, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface; wherein, the simulation time slice is a fixed time length, so that the target lightweight simulation model does not need to accumulate simulation time according to instructions.

[0041] In some embodiments, the scheduling release interface is a time control interface provided in the memory access programming interface of the target lightweight simulation model. When the simulation thread in the target lightweight simulation model is running the firmware program logic, the firmware program logic calls the scheduling release interface to cause the current simulation thread to actively release the simulation time slice it is currently occupying. The released simulation time slice is a pre-set fixed time length, which is a single coarse-grained simulation advancement cycle, rather than a time slice accumulated sequentially for each instruction. The simulation platform is equipped with a simulation kernel, which advances the global simulation time according to the released simulation time slice and switches the simulation execution permission to other simulation threads. The target lightweight simulation model does not need to synchronize the global time every N instructions; the simulation time advancement is explicitly triggered by the scheduling release interface, avoiding quantum synchronization overhead. The call to the scheduling release interface is only used to advance the simulation time; this call is not equivalent to waiting for interrupts or event instructions and does not involve the processor's sleep state.

[0042] In this way, the firmware program logic can advance a simulation time slice of a fixed length at once by calling the scheduling release interface. This eliminates the need to accumulate the execution time of each instruction individually, as is done in instruction-level simulation, and significantly reduces the number of executions in the simulation time advancement process.

[0043] Optionally, based on any of the above embodiments or optional methods, the present disclosure embodiments may also employ the following method, but not limited thereto: the method includes: compiling and linking the firmware to be verified with a simulation library to generate the native executable program; wherein, during the compilation and linking process, the simulation library provides symbolic stubs corresponding to the memory access programming interface, the firmware to be verified provides symbolic definitions corresponding to the symbolic stubs, and the symbolic definitions override the symbolic stubs to bind the firmware to be verified's calls to the memory access programming interface to the internal functions of the target lightweight simulation model.

[0044] In some embodiments, the firmware to be verified is firmware program source code written according to a predefined format, and the simulation library is the underlying program library provided by the simulation runtime environment where the target lightweight simulation model resides. The firmware to be verified is written according to the predefined entry function, implementing the entry function corresponding to the firmware program logic. The firmware to be verified contains firmware program logic and calls to the corresponding predefined APIs. The simulation library predefines symbolic stubs for the memory access programming interface, and the symbolic stubs are empty function implementations with weak symbolic attributes. The firmware to be verified provides symbol definitions corresponding to the memory access programming interface, and the symbol definitions are concrete function implementations with strong symbolic attributes. During the compilation and linking stage, the linker uses symbol binding rules to link the symbols... Symbol resolution prioritizes symbol definitions over symbol stubs, ensuring that symbol definitions in the firmware to be verified override corresponding symbol stubs in the simulation library. Regarding linking order, the firmware to be verified participates in linking before the simulation library to ensure that symbol definitions correctly override symbol stubs in the simulation library. By overriding symbol stubs through symbol definitions, calls to the memory access programming interface by the firmware to be verified are directly bound to the internal function of the target lightweight simulation model after linking. This internal function is the memory address within the target lightweight simulation model that implements the specific functionality of the memory access programming interface. After linking, when the firmware to be verified calls the memory access programming interface at runtime, it directly executes the internal function of the target lightweight simulation model. During the simulation platform model initialization phase, the simulation library establishes binding relationships through a global callback object and registered functions: the member function pointers of the target lightweight simulation model instance are stored in the global callback object so that when the C wrapper function is called, it is forwarded to the corresponding member function of the target lightweight simulation model through the global callback.

[0045] In this way, the firmware to be verified can be symbolically bound to the simulation library during the compilation stage, so that the firmware to be verified can run independently as a local executable program on the host machine without performing an image loading operation during the simulation process.

[0046] Optionally, based on any of the above embodiments or optional methods, the present disclosure embodiments may also employ the following methods, but are not limited thereto: the method includes: during the execution of the firmware program logic by the target lightweight simulation model, when communication with the host-side control logic is required, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface, so that the simulation thread corresponding to the host-side control logic obtains execution permission; wherein, the target lightweight simulation model executes the firmware program logic and the host-side control logic through dual simulation threads respectively.

[0047] In some embodiments, the target lightweight simulation model is configured with two simulation threads, one running firmware program logic and the other running host-side control logic. The two simulation threads share the same startup event, which synchronously triggers their respective execution flows without requiring additional configuration of a separate processor simulation model instance. During the execution of the simulation thread corresponding to the firmware program logic, when the firmware program logic needs to communicate or coordinate with the host-side control logic, the firmware program logic calls the scheduling release interface to release the currently occupied simulation time slice. Upon detecting that the current simulation thread has released its simulation time slice, the simulation kernel in the simulation platform switches the simulation execution permission to the simulation thread corresponding to the host-side control logic, granting it execution permission so that the host-side control logic can perform corresponding control operations.

[0048] In this way, the target lightweight simulation model does not need to set up an additional independent processor simulation instance to achieve dual-role collaboration. Instead, it achieves mutual cooperation between firmware program logic and host-side control logic in the same simulation platform through dual simulation threads and scheduling and release interfaces, reducing the complex synchronization operations of multi-instance processor simulation.

[0049] Optionally, based on any of the above embodiments or optional methods, the present disclosure embodiments may also employ the following method, but not limited thereto: the method includes: encapsulating the memory access request into the bus memory access transaction based on the transaction-level modeling standard, adding a routing extension identifier to the bus memory access transaction, and sending the bus memory access transaction in a single-blocking transaction transmission mode; wherein, the routing extension identifier indicates that the target lightweight simulation model is the origin of this memory access request.

[0050] In some embodiments, after receiving a memory access request from the firmware program logic, the memory access programming interface performs protocol conversion and format encapsulation of the memory access request according to a transaction-level modeling standard. The transaction-level modeling standard includes, but is not limited to, the TLM-2.0 standard. The encapsulated bus memory access transaction includes the target device address information, read / write instructions, and data content of this memory access request. While encapsulating the bus memory access transaction, the target lightweight emulation model adds a routing extension identifier to the bus memory access transaction. The routing extension identifier records information about the target lightweight emulation model as the origin of this memory access request. For example, the memory access programming interface is divided into 8-bit, 16-bit, and 32-bit types based on bit width. It features a 64-bit memory access interface and a system access interface with base address offset to meet bus access requirements of different data widths. The target lightweight simulation model uses a single-blocking transaction transmission mode to send bus memory access transactions. This mode means that the target lightweight simulation model waits for the transaction to complete before returning control. During transmission, the bus memory access transaction is transmitted to the on-chip interconnect network (ISP) via the bus transaction output interface. The ISP routes the bus memory access transaction to the corresponding target device based on the routing extension identifier and target device address information contained in the transaction. Unlike the complete instruction set simulator model, which requires instruction fetching, decoding, and execution through a complete front-end pipeline abstraction, the memory access path disclosed here directly reaches the bus memory access transaction construction with a single memory access programming interface call, eliminating the front-end pipeline abstraction stage.

[0051] In this way, the target lightweight simulation model sends bus memory access transactions through a single blocking transaction transmission mode, which can ensure the transmission integrity of bus memory access transactions in the on-chip interconnect network. At the same time, the origin of this memory access request is accurately identified through the route extension identifier, which helps the on-chip interconnect network to perform transaction tracing and arbitration.

[0052] Optionally, based on any of the above embodiments or optional methods, the present disclosure embodiments may also employ the following methods, but are not limited thereto: the target lightweight simulation model includes a memory access unit, a computing array unit, a memory unit, and a peripheral interface unit; the memory access unit, the computing array unit, the memory unit, and the peripheral interface unit are all connected to the bus transaction output interface, and are uniformly routed to the on-chip interconnect network through the bus transaction output interface.

[0053] In some embodiments, the target lightweight simulation model integrates multiple functional units: a memory access unit for performing direct memory access operations on data, a computing array unit for performing parallel computing acceleration processing, a memory unit for storage and caching, and a peripheral interface unit for handling high-speed input / output communication; the above functional units are respectively connected to the bus transaction output interface through internal interfaces; the memory access requests or control instructions generated by each functional unit are uniformly routed and forwarded to the on-chip interconnect network through the bus transaction output interface.

[0054] In this way, the data interaction between the functional units within the target lightweight simulation model and the bus access to external devices are uniformly sent to the on-chip interconnect network through the bus transaction output interface for centralized routing and scheduling, ensuring the communication uniformity and scalability between internal functional modules.

[0055] Optionally, based on any of the above embodiments or optional methods, the present disclosure embodiments may also employ the following methods, but are not limited thereto: when in a first simulation mode, running the complete instruction set simulator model; when in a second simulation mode, running the target lightweight simulation model.

[0056] In some embodiments, the complete instruction set emulator model includes an instruction set emulation core for executing firmware program logic instruction by instruction through an instruction-level processing pipeline. The complete instruction set emulator model and the target lightweight emulation model are mounted on the same simulation platform and have the same bus interface configuration information. The bus interface configuration information includes configuration parameters such as the physical address mapping of the bus transaction output interface and the peripheral topology connection relationship. The simulation platform is equipped with a configuration switch or configuration register to indicate the current simulation mode of the simulation platform. When the configuration switch is set to the first simulation mode, the simulation platform activates the complete instruction set emulator model and uses the complete instruction set emulator model to run the firmware. When the configuration switch is set to the second simulation mode, the simulation platform activates the target lightweight emulation model and uses the target lightweight emulation model to run the firmware. In the second simulation mode, the target lightweight emulation model runs the firmware program logic by omitting the instruction-level processing pipeline and uses the bus transaction output interface to interact with the on-chip interconnect network and the target device via the bus.

[0057] Through the above methods, the simulation platform can be configured to flexibly switch between high-fidelity simulation mode and high-efficiency simulation mode to meet the needs of different simulation stages and different verification scenarios.

[0058] Figure 2 This is a schematic diagram of the architecture of a target lightweight simulation model provided in an embodiment of the present disclosure, such as... Figure 2As shown, the target lightweight simulation model is set up in a transaction-level simulation platform. The internal units of the target lightweight simulation model include a Direct Memory Access (DMA) unit, a Compute Array unit, and a Memory Unit. The target lightweight simulation model encapsulation module provides a memory access programming interface. The firmware to be verified interacts with the target lightweight simulation model through the memory access programming interface and runs in the execution environment corresponding to the target lightweight simulation model. The target lightweight simulation model is connected to the on-chip interconnect network through the bus transaction output interface. The bus transaction output interface is the transaction-level modeling interface layer (TLM interface layer) in the transaction-level simulation platform. The transaction-level modeling interface layer contains multiple TLM interface sockets for unified routing and output of memory access requests. The memory access unit, computing array unit, memory unit, and peripheral interface unit are all connected to the bus transaction output interface and are uniformly routed to the on-chip interconnect network (NoC) through the bus transaction output interface. The on-chip interconnect network contains a routing and arbitration exchange module for routing and forwarding the bus memory access transactions output by the bus transaction output interface to access the target device. The transaction-level simulation platform also includes a SystemC kernel and transaction-level modeling standards (such as TLM-2.0) to provide an event-driven simulation execution environment and transaction-level communication protocol for the target lightweight simulation model.

[0059] Figure 3 This is a flowchart illustrating a code writing and model deployment process provided in an embodiment of this disclosure, such as... Figure 3 As shown, the firmware to be verified is written, and the entry function corresponding to the firmware program logic is implemented; the firmware to be verified is compiled into a native executable program; the native executable program is compiled and linked with the simulation library; the target lightweight simulation model is deployed in the transaction-level simulation platform; the target lightweight simulation model is connected to the on-chip interconnect network through the bus transaction output interface; shared memory information is injected into the target lightweight simulation model, and the callback corresponding to the firmware program logic is registered; the memory access programming interface is bound to the target lightweight simulation model instance, so that the call of the firmware to be verified to the memory access programming interface is bound to the internal function of the target lightweight simulation model.

[0060] Figure 4 This is a schematic diagram of the execution flow of a firmware running method provided in an embodiment of the present disclosure, as shown below. Figure 4As shown, after the transaction-level simulation platform starts, the simulation thread corresponding to the target lightweight simulation model and the simulation thread corresponding to the host-side control logic are in standby mode. The external master control device performs write operations on the preset registers in the target lightweight simulation model through the on-chip interconnect network. The target lightweight simulation model detects whether the data written in the operation matches the preset trigger flag. When the written data matches the preset trigger flag, the target lightweight simulation model starts running, and the simulation thread enters the entry function of the firmware program logic to start execution. During the execution of the firmware program logic, when the firmware program logic needs to access the target device, the firmware program logic calls the memory access programming interface. Since the firmware to be verified has overridden the simulation through symbol definition during the compilation and linking process, the simulation thread is ready to execute. The symbolic stubs in the real library, the firmware program logic's call to the memory access programming interface, hits a strong symbol through the C wrapper layer and is directly forwarded to the internal function of the target lightweight simulation model; the internal function of the target lightweight simulation model encapsulates the memory access request into a bus memory access transaction and adds a routing extension identifier to the bus memory access transaction; the target lightweight simulation model sends the bus memory access transaction to the on-chip interconnect network via the bus transaction output interface in a single blocking transaction transmission mode; the on-chip interconnect network routes the bus memory access transaction to the target device based on the address information and routing extension identifier in the bus memory access transaction; after the target device responds to the bus memory access transaction, it returns the data back to the target lightweight simulation model via the on-chip interconnect network and the bus transaction output interface.

[0061] Figure 5 This is a flowchart illustrating a simulated thread scheduling method provided in an embodiment of the present disclosure, such as... Figure 5 As shown, during the execution of the firmware program logic in the target lightweight simulation model, the firmware program logic triggers the current simulation thread to release the simulation time slice it occupies by calling the scheduling release interface configured in the memory access programming interface. After the simulation time slice is released, the simulation kernel in the transaction-level simulation platform switches the simulation execution permission to other simulation threads, allowing other simulation threads to obtain execution permission.

[0062] Figure 6 This is a schematic diagram of a memory access path provided in an embodiment of the present disclosure, such as... Figure 6 As shown, during the operation of the target lightweight simulation model, the firmware to be verified calls the memory access programming interface; the firmware to be verified calls the memory access programming interface to the target lightweight simulation model are bound to the internal function of the target lightweight simulation model during the compilation and linking stage; after receiving the call of the memory access programming interface, the internal function encapsulates the memory access request into a bus memory access transaction and sends the bus memory access transaction to the on-chip interconnect network through the bus transaction output interface.

[0063] Figure 7 A schematic diagram of an implementation hierarchy provided for an embodiment of this disclosure, such as... Figure 7As shown, the target lightweight simulation model logically comprises a firmware layer, an interface layer, a bridge layer, a model layer, and an interconnect layer. In the firmware layer, the firmware to be verified implements its program logic according to the agreed-upon entry function. In the interface layer, a memory access programming interface and a scheduling and release interface are configured. In the bridge layer, symbol stubs are overridden during the compilation and linking process, binding the firmware's calls to the memory access programming interface to the internal functions of the target lightweight simulation model. In the model layer, the target lightweight simulation model constructs bus memory access transactions and runs the firmware program logic and host-side control logic through dual simulation threads. In the interconnect layer, bus memory access transactions are sent to the on-chip interconnect network via the bus transaction output interface to access the target device.

[0064] Figure 8 This is a schematic diagram of a memory access call process provided in an embodiment of the present disclosure, such as... Figure 8 As shown, during the execution of firmware program logic in the target lightweight simulation model, the firmware to be verified initiates a memory access request by calling the memory access programming interface. The firmware's call to the memory access programming interface has already had its symbolic stubs overridden during the compilation and linking phase, thus the linker resolves to the strong symbolic implementation in the simulation library. The strong symbolic implementation in the simulation library forwards the call parameters to the global callback and calls the corresponding internal function of the target lightweight simulation model through the global callback. The internal function of the target lightweight simulation model responds to this call by constructing the memory access request as a bus memory access transaction and adding a routing extension identifier to the bus memory access transaction. It then sends the transaction to the on-chip interconnect network (ISP) through the bus transaction output interface in a single-blocking transaction transmission mode. The ISP receives the bus memory access transaction and responds. The response data returns to the firmware to be verified via the bus transaction output interface, the internal function of the target lightweight simulation model, the simulation library, and the memory access programming interface.

[0065] Corresponding to the firmware running method described above, this invention also proposes a firmware running device. Since the device embodiments of this invention correspond to the method embodiments described above, details not disclosed in the device embodiments can be referred to in the method embodiments described above, and will not be repeated here.

[0066] Figure 9 This is a schematic diagram of the structure of a firmware running device provided in an embodiment of the present disclosure, as shown below. Figure 9 As shown, it includes: compilation unit 21, execution unit 22, and packaging unit 23.

[0067] Compilation unit 21 is used to compile the firmware to be verified into a local executable program; The execution unit 22 is used to run the firmware program logic corresponding to the local executable program in the local execution environment by the target lightweight simulation model; wherein, the target lightweight simulation model omits the instruction-level processing pipeline, is connected to the on-chip interconnect network through the bus transaction output interface, and is configured with a memory access programming interface, and is configured to have the same bus interface configuration information as the full instruction set emulator model, so that the target lightweight simulation model runs in place of the full instruction set emulator model; The encapsulation unit 23 is used to encapsulate the memory access request generated by the firmware program logic into a bus memory access transaction when the firmware program logic calls the memory access programming interface; wherein the bus memory access transaction is sent to the on-chip interconnect network via the bus transaction output interface to access the target device.

[0068] In summary, the firmware execution device provided in this disclosure includes: compiling the firmware to be verified into a native executable program, and having the target lightweight simulation model run the firmware program logic corresponding to the native executable program in a local execution environment; wherein, the target lightweight simulation model omits the instruction-level processing pipeline, connects to the on-chip interconnect network through a bus transaction output interface, and is configured with a memory access programming interface; when the firmware program logic calls the memory access programming interface, the memory access request generated by the firmware program logic is encapsulated into a bus memory access transaction; wherein, the bus memory access transaction is sent to the on-chip interconnect network through the bus transaction output interface to access the target device; thereby, sending the bus memory access transaction and accessing the target device can be completed without executing each instruction-level processing pipeline, shortening the simulation verification cycle.

[0069] Furthermore, in one possible implementation of this disclosure, the apparatus is further configured to: After the compilation unit compiles the firmware to be verified into a local executable program, the write operation to the preset register in the target lightweight simulation model is detected through the on-chip interconnect network. When the data of the write operation matches the preset trigger identifier, the target lightweight simulation model is triggered to start running the firmware program logic.

[0070] Furthermore, in one possible implementation of this disclosure, the apparatus is further configured to: During the execution of the firmware program logic by the target lightweight simulation model, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface; wherein, the simulation time slice is a fixed time length, so that the target lightweight simulation model does not need to accumulate simulation time according to each instruction.

[0071] Furthermore, in one possible implementation of this disclosure, the compilation unit is further configured to: The firmware to be verified is compiled and linked with the simulation library to generate the native executable program. During the compilation and linking process, the simulation library provides symbolic stubs corresponding to the memory access programming interface, and the firmware to be verified provides symbolic definitions corresponding to the symbolic stubs. The symbolic definitions override the symbolic stubs, binding the firmware to be verified's calls to the memory access programming interface to the internal functions of the target lightweight simulation model.

[0072] Furthermore, in one possible implementation of this disclosure, the apparatus is further configured to: During the execution of the firmware program logic in the target lightweight simulation model, when communication with the host-side control logic is required, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface, so that the simulation thread corresponding to the host-side control logic can obtain execution permission; wherein, the target lightweight simulation model runs the firmware program logic and the host-side control logic through dual simulation threads respectively.

[0073] Furthermore, in one possible implementation of this disclosure, the encapsulation unit is further configured to: Based on the transaction-level modeling standard, the memory access request is encapsulated as the bus memory access transaction, and a route extension identifier is added to the bus memory access transaction. The bus memory access transaction is sent in a single blocking transaction transmission mode. The route extension identifier indicates that the target lightweight simulation model is the origin of this memory access request.

[0074] Furthermore, in one possible implementation of this disclosure embodiment, the target lightweight simulation model includes a memory access unit, a computing array unit, a memory unit, and a peripheral interface unit; The memory access unit, the computing array unit, the memory unit, and the peripheral interface unit are all connected to the bus transaction output interface and are uniformly routed to the on-chip interconnect network through the bus transaction output interface.

[0075] Furthermore, in one possible implementation of this disclosure, the apparatus is further configured to: When in the first simulation mode, the complete instruction set simulator model is used for operation; When in the second simulation mode, the target lightweight simulation model is used for operation.

[0076] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of the embodiments of this disclosure, and the principle is the same. Therefore, the embodiments of this disclosure are not limited thereto.

[0077] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0078] Figure 10 A schematic block diagram of an example electronic device 1200 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0079] like Figure 10 As shown, the electronic device 1200 includes a computing unit 1201, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory 1202 or a computer program loaded from a storage unit 1208 into a random access memory 1203. The random access memory 1203 may also store various programs and data required for the operation of the electronic device 1200. The computing unit 1201, the read-only memory 1202, and the random access memory 1203 are interconnected via a bus 1204. An input / output interface 1205 is also connected to the bus 1204.

[0080] Multiple components in electronic device 1200 are connected to input / output interface 1205, including: input unit 1206, such as keyboard, mouse, etc.; output unit 1207, such as various types of monitors, speakers, etc.; storage unit 1208, such as disk, optical disk, etc.; and communication unit 1209, such as network card, modem, wireless transceiver, etc. Communication unit 1209 allows electronic device 1200 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0081] The computing unit 1201 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1201 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 1201 performs the various methods and processes described above, such as firmware execution methods. For example, in some embodiments, the firmware execution method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1208. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 1200 via read-only memory 1202 and / or communication unit 1209. When the computer program is loaded into random access memory 1203 and executed by the computing unit 1201, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the computing unit 1201 may be configured to execute the aforementioned firmware operation method by any other suitable means (e.g., by means of firmware).

[0082] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0083] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0084] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0085] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0086] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0087] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service system that addresses the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0088] It's important to note that artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies primarily include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0089] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0090] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A firmware running method, characterized in that, include: The firmware to be verified is compiled into a native executable program, and the firmware program logic corresponding to the native executable program is run by the target lightweight simulation model in the local execution environment. The target lightweight simulation model omits the instruction-level processing pipeline, connects to the on-chip interconnect network through the bus transaction output interface, and is configured with a memory access programming interface. The target lightweight simulation model is configured to have the same bus interface configuration information as the full instruction set emulator model, so that the target lightweight simulation model can run in place of the full instruction set emulator model. When the firmware program logic calls the memory access programming interface, the memory access request generated by the firmware program logic is encapsulated into a bus memory access transaction; wherein, the bus memory access transaction is sent to the on-chip interconnect network via the bus transaction output interface to access the target device.

2. The method according to claim 1, characterized in that, After compiling the firmware to be verified into a native executable program, the method further includes: Write operations to preset registers in the target lightweight simulation model are detected through the on-chip interconnect network; When the data of the write operation matches the preset trigger identifier, the target lightweight simulation model is triggered to start running the firmware program logic.

3. The method according to claim 1, characterized in that, The method further includes: During the execution of the firmware program logic by the target lightweight simulation model, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface; wherein, the simulation time slice is a fixed time length, so that the target lightweight simulation model does not need to accumulate simulation time according to each instruction.

4. The method according to claim 1, characterized in that, The step of compiling the firmware to be verified into a native executable program includes: The firmware to be verified is compiled and linked with the simulation library to generate the native executable program. During the compilation and linking process, the simulation library provides symbolic stubs corresponding to the memory access programming interface, and the firmware to be verified provides symbolic definitions corresponding to the symbolic stubs. The symbolic definitions override the symbolic stubs, binding the firmware to be verified's calls to the memory access programming interface to the internal functions of the target lightweight simulation model.

5. The method according to claim 1, characterized in that, The method further includes: During the execution of the firmware program logic in the target lightweight simulation model, when communication with the host-side control logic is required, the firmware program logic releases the simulation time slice of the current simulation thread by calling the scheduling release interface configured in the memory access programming interface, so that the simulation thread corresponding to the host-side control logic can obtain execution permission; wherein, the target lightweight simulation model runs the firmware program logic and the host-side control logic through dual simulation threads respectively.

6. The method according to claim 1, characterized in that, The step of encapsulating the memory access request generated by the firmware program logic into a bus memory access transaction includes: Based on the transaction-level modeling standard, the memory access request is encapsulated as the bus memory access transaction, and a route extension identifier is added to the bus memory access transaction. The bus memory access transaction is sent in a single blocking transaction transmission mode. The route extension identifier indicates that the target lightweight simulation model is the origin of this memory access request.

7. The method according to claim 1, characterized in that, The target lightweight simulation model includes a memory access unit, a computing array unit, a memory unit, and a peripheral interface unit. The memory access unit, the computing array unit, the memory unit, and the peripheral interface unit are all connected to the bus transaction output interface and are uniformly routed to the on-chip interconnect network through the bus transaction output interface.

8. The method according to claim 1, characterized in that, The method further includes: When in the first simulation mode, the complete instruction set simulator model is used for operation; When in the second simulation mode, the target lightweight simulation model is used for operation.

9. A firmware running device, characterized in that, include: The compilation unit is used to compile the firmware to be verified into a native executable program. The execution unit is used to run the firmware program logic corresponding to the local executable program in the local execution environment by the target lightweight simulation model; wherein, the target lightweight simulation model omits the instruction-level processing pipeline, is connected to the on-chip interconnect network through a bus transaction output interface, and is configured with a memory access programming interface, and is configured to have the same bus interface configuration information as the full instruction set emulator model, so that the target lightweight simulation model can run in place of the full instruction set emulator model; An encapsulation unit is used to encapsulate the memory access request generated by the firmware program logic into a bus memory access transaction when the firmware program logic calls the memory access programming interface; wherein the bus memory access transaction is sent to the on-chip interconnect network via the bus transaction output interface to access the target device.

10. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

Images