Memory access method, memory protection unit, system on chip, and storage medium

Abstract

The application discloses a memory access method, a memory protection unit, a system on chip and a storage medium, and belongs to the chip technical field. The method is applied to the memory protection unit, the memory protection unit comprises at least one arbitration node, a plurality of input / output bridges and a plurality of checkers, the arbitration node is arranged between the plurality of input / output bridges and the plurality of checkers, and the method comprises the following steps: receiving a memory access request sent by an external device through an input / output bridge and sending the memory access request to the arbitration node; determining a target checker from the plurality of checkers according to traffic information of the plurality of checkers through the arbitration node, and forwarding the memory access request to the target checker; checking the memory access permission of the external device through the target checker, obtaining a checking result, and returning the checking result to the input / output bridge through the arbitration node; and the checking result is used to represent whether the external device passes the permission check. The application can solve the problem that the existing physical memory input / output protection method is low in efficiency.

Description

Technical Field

[0001] This application belongs to the field of chip technology, specifically relating to a memory access method, a memory protection unit, a system-on-a-chip, and a storage medium. Background Technology

[0002] With the rise of technologies such as the Internet of Things (IoT), 5G, artificial intelligence, and big data analytics, the demand for physical memory protection capabilities in System-on-Chip (SoC) is increasing. In related technologies, when an external device sends an access request to memory, a single Input / Output Physical Memory Protection (IOPMP) unit with an integrated checker determines whether these access requests comply with preset security rules, and accordingly allows or blocks the request, thereby preventing unsafe memory access.

[0003] However, existing physical memory input / output protection methods are relatively simple. In large and complex SoC application scenarios, as the number of external devices increases, the preset security rules that need to be adopted become more and more complex. Especially when there are a large number of access requests, a single IOPMP may become inefficient, which will affect the system performance. Summary of the Invention

[0004] The purpose of this application is to provide a memory access method, a memory protection unit, a system-on-a-chip, and a storage medium, which can solve the problem that existing physical memory input / output protection methods are relatively simple and inefficient.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a memory access method applied to a memory protection unit. The memory protection unit includes at least one arbitration node, multiple input / output bridges, and multiple checkers. The arbitration node is deployed between the multiple input / output bridges and the multiple checkers. The input / output bridges are used to connect external devices to the bus of the system-on-a-chip. The method includes:

[0007] The input / output bridge receives memory access requests sent by the external device and sends them to the forwarding node.

[0008] The arbitration node determines the target checker from the multiple checkers based on the traffic information of the multiple checkers, and forwards the memory access request to the target checker.

[0009] The target checker verifies the memory access permissions of the external device, obtains the check result, and returns the check result to the input / output bridge through the arbitration node; the check result includes whether the external device passes the permission verification.

[0010] Secondly, embodiments of this application provide a memory protection unit, which includes at least one arbitration node, multiple input / output bridges, and multiple checkers. The arbitration node is deployed between the multiple input / output bridges and the multiple checkers. The input / output bridges are used to connect external devices to the system-on-a-chip bus.

[0011] The input / output bridge is used to receive memory access requests sent by the external device and send them to the forwarding node;

[0012] The arbitration node is used to determine the target inspector from the plurality of inspectors based on the traffic information of the plurality of inspectors, and forward the memory access request to the target inspector;

[0013] The target checker is used to verify the memory access permissions of the external device, obtain the check result, and return the check result to the input / output bridge through the arbitration node; the check result includes whether the external device passes the permission verification.

[0014] Thirdly, embodiments of this application provide an electronic device including the memory protection unit described in the second application.

[0015] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0016] In this embodiment, the memory protection unit includes an arbitration node, an input / output bridge, and a checker. The arbitration node is positioned between the checker and the input / output bridge. The input / output bridge connects external devices to the on-chip system bus, and the checker verifies the memory access permissions of the external devices. Compared to the existing architecture that integrates the checker into the input / output physical memory protection unit, this approach decouples the checker and the input / output bridge and then interconnects them via the arbitration node. This allows for flexible configuration of the number and relative positions of the checkers and input / output bridges, reducing hardware design complexity and supporting expansion of the number of external devices and checkers in large and complex SoC applications. Furthermore, when there are many external devices, the arbitration node can schedule memory access requests based on the checker's traffic information, rationally allocating them to different checkers. This not only verifies the memory access permissions of multiple external devices but also improves the system's memory access throughput through dynamic scheduling, increasing the utilization of on-chip system hardware resources and facilitating load balancing. Compared to the existing architecture of a single input / output physical memory protection unit, this approach reduces resource contention in high-concurrency scenarios and improves the protection efficiency of physical memory input / output. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a memory protection unit provided in an embodiment of this application.

[0018] Figure 2 This is a schematic diagram of another memory protection unit provided in an embodiment of this application.

[0019] Figure 3 This is a flowchart of a memory access method provided in an embodiment of this application.

[0020] Figure 4 This is a flowchart illustrating the specific steps of a memory access method provided in an embodiment of this application.

[0021] Figure 5 This is a flowchart of a protocol format conversion provided in an embodiment of this application.

[0022] Figure 6 This is a schematic diagram of an input / output bridge and a checker interconnected via an arbitration node, as provided in an embodiment of this application.

[0023] Figure 7 This is a flowchart illustrating how to verify the memory access permissions of an external device, as provided in an embodiment of this application.

[0024] Figure 8 This is a schematic diagram of a forwarding logic for an error response in the prior art.

[0025] Figure 9This is a schematic diagram of an error response forwarding logic provided in an embodiment of this application.

[0026] Figure 10 This is a flowchart of another memory access method provided in the embodiments of this application.

[0027] Figure 11 This is a block diagram of a memory access device provided in an embodiment of this application.

[0028] Figure 12 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0031] A System-on-Chip (SoC) is an integrated circuit technology that integrates a complete electronic system onto a single chip. An SoC includes not only hardware components but also embedded software, enabling it to perform specific functions.

[0032] A graphics processing unit (GPU), also known as a display core, visual processor, or display chip, is a microprocessor specifically designed for performing image and graphics-related calculations in personal computers, workstations, game consoles, and some mobile devices.

[0033] The central processing unit (CPU), also known as the processor, is the core of a computer system for computing and control, and is the final execution unit for information processing and program execution.

[0034] With the rise of technologies such as the Internet of Things (IoT), 5G communication, artificial intelligence, and large-scale models, the demand for physical memory protection capabilities in SoC systems is increasing. While input / output (I / O) proxies such as direct memory access (DMA) can improve system performance, they also expose the system to vulnerabilities such as DMA attacks. A Trusted Execution Environment (TEE) constructs a secure area within the central processing unit (CPU) through hardware and software methods, ensuring the confidentiality and integrity of programs and data loaded within it. Even if an attacker compromises the untrusted parts of the system, they cannot interfere with the secure operation of programs within the TEE or steal sensitive data.

[0035] There are already relatively complete solutions for building trusted execution environments, such as the fifth-generation Reduced Instruction Set Computer (RISC). RISC-V is an open-source instruction set architecture. In the RISC-V ecosystem, PMP and ePMP already exist, providing standard protection schemes for access from RISC-V hardware threads (hardware threads, hart) to the physical address space, but there is no equivalent standard to protect non-CPU bootloaders.

[0036] Modern computer chips, especially those designed for artificial intelligence (AI) and high-performance computing, are becoming increasingly large-scale SoCs. In large SoC architectures such as network-on-chip (NoC), there are numerous external devices (referred to as "peripherals"). Existing physical memory input / output protection methods are relatively simple, and simply increasing the complexity of a single IOPMP is insufficient. This not only increases the complexity of IOPMP and the difficulty of debugging, but also affects system performance.

[0037] Especially during the back-end design process, external devices may be distributed around the chip. Isolating and protecting all paths from these external devices to the on-chip system bus using IOPMP is challenging. Not only is it difficult for a single high-performance IOPMP to protect all peripherals' memory read and write operations, but it also poses a challenge to SoC placement and routing. Current technologies typically rely on multiple instantiations to adapt to large SoC applications, lacking a flexible solution, which leads to significant resource waste.

[0038] To address the aforementioned problems, this application provides a memory access method, a memory protection unit, a system-on-a-chip, and a storage medium. The memory access method provided by the embodiments of this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0039] Figure 1 This is a schematic diagram of a memory protection unit provided in an embodiment of this application. See also... Figure 1 The memory access method provided in this application embodiment can be applied to, for example, Figure 1 The architecture of the memory protection unit shown is as follows.

[0040] In this embodiment, the memory protection unit includes at least one arbitration node, multiple input / output bridges, and multiple checkers. The arbitration node is deployed between the multiple input / output bridges and the multiple checkers. The input / output bridges are used to connect external devices to the system-on-a-chip bus.

[0041] It is understandable that peripherals are generally located at the edge of the chip, at a considerable distance, and the paths between peripherals and the SoC bus are relatively dispersed. Peripherals are typically directly connected to the on-chip network, either individually or several peripherals are connected to the on-chip network through a bridge. In this embodiment, the protection behavior of IOPMP is divided into two parts: a checker and an I / O bridge. The checker and bridge are decoupled, and can be placed independently in different areas of the SoC, facilitating layout and routing.

[0042] In some embodiments, to better optimize system performance, a one-to-one correspondence between the checker and the bridge is no longer required; an arbitrator is inserted for forwarding. Multiple memory access requests are allocated reasonably based on the load and processing capacity of each party, for example, by allocating multiple bridge request and checker response interfaces for query requests, thus achieving optimal query speed.

[0043] In some embodiments, an I / O bridge and checker are inserted on the path between the peripheral and the on-chip network to isolate and check the peripheral's requests for system memory.

[0044] In some embodiments, the memory protection unit supports m bridges and n checkers, where m and n are both positive integers. The IO bridges and checkers can be interconnected via an arbiter. The arbiter is used for interconnection between different numbers of bridges and checkers, and also performs flow control, distributing memory access requests to idle checkers based on their status to improve system performance.

[0045] In some embodiments, the memory access unit employs a multi-region architecture, comprising multiple independent regions. Each region includes at least one input / output bridge and at least one checker; at least one region among the multiple regions deploys an arbitration node for forwarding memory access requests.

[0046] In some embodiments, memory access requests include query requests, memory read / write requests, etc.

[0047] For example, taking the sending of a query request by a peripheral device in an on-chip network as an example, see [link to relevant documentation]. Figure 2 The memory access unit comprises at least two regions, namely region 0 and region 1. The checker and the input / output bridges are decoupled. The input / output bridges are positioned within a preset range of the external device; this preset range varies depending on the SoC and is influenced by factors such as package size and the number of peripherals. For example, the input / output bridges may be positioned at the edge of the SoC, surrounding the core logic area, with a radial width between the input / output bridges and the external device ranging from 0.5 mm to 2 mm. This shortens the path for peripherals to connect to the on-chip system, facilitating centralized management of multiple interfaces and optimizing routing on large SoCs.

[0048] In some embodiments, the memory access unit includes at least two regions that are physically non-adjacent and located around the chip. For example, the at least two regions include region 0 and region 1. Region 0 is located in a ring-shaped area 0-1 mm from the left edge of the chip, and region 1 is located at the right edge. In this way, the checker and the input / output bridge are connected via an arbitration node. The checker, input / output bridge, and arbitration node are distributed in different physical locations within the system, effectively solving the back-end layout and routing problems.

[0049] It's important to note that an area can have zero arbitration nodes, one arbitration node, or multiple arbitration nodes. For example, edge areas do not require arbitration, therefore, no arbitration nodes are deployed in edge areas. Conversely, areas with a large number of peripherals and high request throughput require the deployment of multiple arbitration nodes.

[0050] In some embodiments, the number of arbitration nodes deployed in each region is determined based on the number of external devices accessing each region and the expected concurrency of memory access requests.

[0051] In some embodiments, the number of input / output bridges and checkers is determined based on the on-chip system area, path throughput, operating frequency, etc.

[0052] In other embodiments, customized IOPMP designs are performed through simulation, allocating IOPMP cells of different capacities to the SoC region and external devices as needed.

[0053] The memory access method provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0054] Figure 3 This is a flowchart of a memory access method provided in an embodiment of this application, applied to... Figure 1 or Figure 2 The method includes the following steps for the memory protection unit in the memory.

[0055] Step 101: Receive memory access requests from external devices via the input / output bridge and send them to the arbitration node.

[0056] In this embodiment of the application, the input / output bridge (IO bridge) is used to connect external devices to the internal bus of the system on the chip, enabling various external devices to communicate with the memory, CPU, accelerator, etc. inside the system on the chip.

[0057] In some embodiments, a memory access request sent by an external device is received through an input / output bridge, and parameter information in the memory access request is extracted. The parameter information includes address information, transaction type, request identifier, and device identifier. The parameter information is integrated through the input / output bridge according to the protocol format of the on-chip system bus to obtain a standard access request. The standard access request is sent to the arbitration node through the input / output bridge.

[0058] In one possible implementation, the DMA memory access request is converted into an AXI (Advanced eXtensible Interface) bus format via an input / output bridge, and the response data from the memory is received and forwarded to the DMA buffer, so that external devices can communicate directly with the memory without CPU intervention.

[0059] In some embodiments, the memory access unit adopts a multi-region architecture, including multiple independent regions. Each region includes at least one input / output bridge and at least one checker; at least one region in the multiple regions deploys an arbitration node for forwarding memory access requests; prior to step 101, the memory access method may further include: determining the number of arbitration nodes deployed in each region based on the number of external devices connected to the region and the expected concurrency of memory access requests.

[0060] For example, based on the number of external devices and the concurrency of memory access requests, calculate the maximum number of requests that all external devices in the region can initiate simultaneously; based on the maximum number and the maximum number of requests that a single arbitration node can schedule per second, calculate the number of arbitration nodes to deploy.

[0061] Step 102: The arbitration node determines the target inspector from multiple inspectors based on the traffic information of multiple inspectors and forwards the memory access request to the target inspector.

[0062] In some embodiments, traffic information includes the amount of cached data in the queue, the average time to process a single request, and hardware resource utilization.

[0063] In some embodiments, a target inspector is determined from multiple inspectors based on the amount of cached data in multiple inspector queues, the average time to process a single request, and the hardware resource utilization, and the memory access request is forwarded to the target inspector.

[0064] In some embodiments, the arbitration node selects the checker with the lowest hardware resource utilization as the target checker based on the traffic information of multiple checkers, and forwards the memory access request to the target checker.

[0065] In other embodiments, when there are multiple input / output bridges initiating multiple memory access requests, the arbitration node obtains the preset priorities of the multiple input / output bridges and uses the priorities of the multiple input / output bridges as the priorities of the multiple memory access requests; the arbitration node matches each memory access request to a corresponding target checker according to the traffic information of multiple checkers in descending order of priority; and the arbitration node forwards the multiple memory access requests to the target checker corresponding to each memory access request in descending order of priority.

[0066] In other embodiments, for any memory access request, the amount of cached data in the queues of multiple checkers is compared by an arbitration node; the checker with the lowest amount of cached data in its queue is selected as the target checker by the arbitration node, and the memory access request is forwarded to the target checker.

[0067] Step 103: Verify the memory access permissions of the external device through the target checker, obtain the check result, and return the check result to the input / output bridge through the arbitration node.

[0068] In this embodiment of the application, the inspection result is used to characterize whether the external device passes the permission verification.

[0069] In some embodiments, the checker pre-stores memory access rules configured by the on-chip system, such as memory address access ranges and read / write permission levels for different types of external devices.

[0070] In some embodiments, the inspector stores an authorization data table in a hardware register or a dedicated storage unit. This authorization data table includes authorized address ranges and allowed transaction types for different external devices.

[0071] In some embodiments, the target checker extracts the address information and transaction type from the memory access request; the target checker queries a preset permission data table based on the address information and transaction type to determine whether the memory access request matches the permission data table; if the memory access request matches the permission data table, the target checker generates a check result indicating that the external device has passed the permission verification, and returns the check result to the input / output bridge through the arbitration node.

[0072] In some embodiments, after step 103, the memory access method further includes: if the check result indicates that the external device passes the permission verification, allowing the memory access request through the input / output bridge so that the external device can access the memory through the system-on-a-chip bus; if the check result indicates that the external device fails the permission verification, performing an error handling operation through the input / output bridge, wherein the error handling operation includes an interrupt error handling operation and a data error handling operation.

[0073] In some embodiments, there may be multiple checkers in the same SoC system, and each checker needs to be configured separately; before step 103, the above memory access method further includes: detecting the version information of the hardware system and initializing the configuration of each checker according to the hardware capabilities.

[0074] In summary, in this embodiment, the memory protection unit includes an arbitration node, an input / output bridge, and a checker. The arbitration node is positioned between the checker and the input / output bridge. The input / output bridge connects external devices to the on-chip system bus, and the checker verifies the memory access permissions of external devices. Compared to the existing architecture that integrates the checker into the input / output physical memory protection unit, this approach decouples the checker and the input / output bridge and then interconnects them via the arbitration node. This allows for flexible configuration of the number and relative positions of the checkers and input / output bridges, reducing hardware design complexity and supporting expansion of the number of external devices and checkers in large and complex SoC applications. Furthermore, when there are many external devices, the arbitration node can schedule memory access requests based on the checker's traffic information, rationally allocating them to different checkers. This not only verifies the memory access permissions of multiple external devices but also improves the system's memory access throughput through dynamic scheduling, enhancing the utilization of on-chip system hardware resources and facilitating load balancing. Compared to the existing architecture of a single input / output physical memory protection unit, this approach reduces resource contention in high-concurrency scenarios and improves the protection efficiency of physical memory input / output.

[0075] Figure 4 This is a flowchart illustrating the specific steps of a memory access method provided in this application embodiment, applied to a memory protection unit. The method includes the following steps.

[0076] Step 201: Receive memory access requests sent by external devices through the input / output bridge and extract parameter information from the memory access requests.

[0077] In this embodiment of the application, the parameter information includes address information, transaction type, request identifier, and device identifier.

[0078] For example, address information includes the physical address of the target memory, address length, etc.; transaction type includes read operation, write operation, burst transfer identifier, etc.; request identifier is a unique identifier (Identity document, ID) for memory access requests, and the entire group of requests shares the same request identifier during burst transfer; device identifier is a unique ID of the external device that initiated the request, such as a device security identifier (SID).

[0079] In some embodiments, the input / output bridge includes a peripheral interface for receiving memory access requests, such as a Peripheral Component Interconnect Express Root Port (PCIe Root Port), a Serial Peripheral Interface (SPI), or an AXI Slave interface.

[0080] In some embodiments, the input / output bridge receives raw memory access requests sent by external devices, such as PCIe Transaction Layer Packet (TLP), SPI frames, AXI transactions, etc.

[0081] In some embodiments, the raw memory access request is parsed through the input / output bridge to extract address information, transaction type, request identifier, and device identifier.

[0082] Step 202: The parameter information is integrated according to the protocol format of the on-chip system bus through the input / output bridge to obtain the standard access request, and the standard access request is sent to the arbitration node.

[0083] In some embodiments, the protocol format of the upper system bus may be AXI, AHB (Advanced High-performance Bus), etc.

[0084] For example, the peripheral is a PCIe device, and the original memory access request it initiates is in TLP packet format. Extracting the parameter information from the original memory access request yields address = 0x2000_0000, transaction type = write, and device ID = 0x03. The IO bridge then converts this into a standard AXI4 format request.

[0085] AWADDR=0x2000_0000 (address information), AWID=0x05 (generated request ID), AWPROT=0x01 (write transaction type), USER=0x03 (device ID), and pull the AWVALID signal high to indicate that the request is valid.

[0086] In other embodiments, the input / output bridge includes: an AXI request processing module, an AXI auxiliary channel (auxchannel), and a bridge first-in-first-out (FIFO) cache. Parameter information includes the original ID, read / write channel, access address, burst length, and bit width. The original ID is the request identifier and / or device identifier, and the read / write channel represents the channel corresponding to the transaction type. Step 202 may include:

[0087] Sub-step 2021 involves simplifying the original ID, read / write channel, access address, burst length, and bit width using the AXI request processing module to obtain simplified parameters.

[0088] Sub-step 2022: The simplified parameters are packaged into binary data by the AXI request processing module and written into the bridge FIFO through the AXI auxiliary channel;

[0089] Sub-step 2023 involves temporarily storing binary data in a bridge FIFO and asynchronously forwarding the standard access request corresponding to the simplified parameters to the arbitrator based on the binary data and handshake signals.

[0090] In one possible implementation, sub-step 2021 includes: truncating the original ID to obtain the identity identifier; converting the read / write channel to the request type corresponding to the protocol format; calculating the total number of bytes transmitted based on the burst length and bit width; and using the identity identifier, request type, access address, and total number of bytes transmitted as simplified parameters.

[0091] For example, the original ID is the AXI transaction ID. The 16-bit AXI transaction ID is truncated to obtain an 8-bit identity identifier, which is adapted to the ID bit width requirements of the arbiter and checker. The request type is distinguished by the selector, and the AXI channel distinction is converted into a single-bit type identifier, which simplifies the judgment logic of subsequent permission verification. The original address information is forwarded directly without modification. len=4 and size=2, corresponding to 4 bytes. The burst length and bit width are converted into the total number of bytes transmitted by calculation. The total number of bytes = 4×4=16, which is the transmission length format that can be recognized by the arbiter and checker.

[0092] In one possible implementation, the IO bridge truncates or integrates the ID in the original request, i.e., ARID / WID, to obtain the external device's identity document (Request Role Identity Document, rrid).

[0093] In one possible implementation, the AXI Slave port clock of the input / output bridge is the peripheral-side clock, while the arbitrator clock is the SoC's internal bus clock; these two may differ. The Bridge FIFO is used to buffer request information, enabling secure data transfer across clock domains and avoiding timing conflicts.

[0094] In another possible implementation, when multiple AXI requests arrive concurrently, the bridge FIFO can temporarily cache simplified data for these requests to prevent the arbitrator from being overwhelmed by instantaneous traffic; it forwards the requests to the arbitrator in a first-in-first-out order to ensure the processing order of the requests.

[0095] For example, Figure 5 This is a flowchart illustrating a protocol format conversion method provided in an embodiment of this application. See also... Figure 5 The input / output bridge receives raw memory access requests from the AXI Slave port, extracts fields such as id, ar / aw, addr, and len+size through the AXI request processing module, performs truncation, selection, pass-through, and calculation on each field to generate simplified parameters rrid, rw, addr, and len, and packages these simplified parameters into a set of binary data (bits) through the AXI request processing module and writes them to the FIFO buffer through the AXI auxiliary channel. The simplified request is then asynchronously forwarded to the arbitrator through the bridge FIFO handshake signals (valid, ready).

[0096] In one possible implementation, the bridge FIFO uses handshake signals for check responses (checkrsp). The handshake signals include valid data and ready to receive. Valid is used to inform the arbitrator that there is a new request, and ready is used to inform the IO bridge that it can receive the request.

[0097] In some embodiments, in addition to the original ID, read / write channel, access address, burst length, and bit width, the AXI auxiliary channel is also used to transmit burst type (burst), lock type (lock), cache attribute (cache), protection unit attribute (prot), quality of service (QoS), region selection (region), and user-defined signal (user). Since these signals are unrelated to IOPMP rule checks, they do not participate in peripheral access control.

[0098] In some embodiments, there may be multiple memory access requests, which may be initiated by different input / output bridges or by the same input / output bridge.

[0099] In some embodiments, when multiple peripheral requests are received simultaneously on any input / output bridge, they are sorted in the input / output bridge FIFO according to device priority or request arrival order, and then forwarded to the arbitration node in sequence to avoid concurrent request conflicts.

[0100] Step 203: When there are multiple input / output bridges initiating multiple memory access requests, the preset priorities of the multiple input / output bridges are obtained through the arbitration node, and the priorities of the multiple input / output bridges are used as the priorities of the multiple memory access requests.

[0101] In some embodiments, complex SoCs typically have multiple I / O bridges, each connecting one or more types of peripherals. The importance of the services associated with different I / O bridges varies greatly, and therefore, the priority of memory access requests associated with different I / O bridges is different.

[0102] For example, the I / O bridge connected to the GPU corresponds to real-time rendering, while the I / O bridge connected to the sensor corresponds to low-speed data acquisition. Therefore, memory access requests from the I / O bridge connected to the GPU have a higher priority than memory access requests from the I / O bridge connected to the sensor.

[0103] For example, high-priority devices can be queried first, such as video streams that require fixed-frequency output, GPUs, and communication traffic; while low-priority devices can have their query priority reduced, such as network storage, software loading, and file copying.

[0104] In one possible implementation, the arbitration node obtains the priority of each I / O bridge through a pre-configured hardware register; all memory access requests initiated by each I / O bridge directly inherit the priority of that I / O bridge.

[0105] For example, IO bridge 1 connects to the GPU, IO bridge 2 connects to the sensor, and IO bridge 3 connects to the PCIe device, and all three send requests simultaneously; the priority is divided into 4 levels, with level 3 being the highest and level 0 being the lowest; IO bridge 1 is set to level 3, IO bridge 2 is set to level 1, and IO bridge 3 is set to level 2. All GPU requests from IO bridge 1 are level 3, all sensor requests from IO bridge 2 are level 1, and all PCIe device requests from IO bridge 3 are level 1.

[0106] Step 204: The arbitration node matches the corresponding target checker for each memory access request in descending order of priority based on the traffic information of multiple checkers.

[0107] In some embodiments, each I / O bridge has an input buffer queue, and each checker also has an output buffer queue. Arbitration nodes control the flow of requests to balance the buffers in the queues corresponding to the I / O bridges and checkers.

[0108] For example, the arbitration node receives multiple memory access requests, including: a GPU request from IO Bridge 1 (level 3), a PCIe request from IO Bridge 3 (level 2), a sensor request from IO Bridge 2 (level 1), and another GPU request from IO Bridge 1 (level 3). These requests are sorted by priority, resulting in the following queue: GPU request 1 (level 3), GPU request 2 (level 3), PCIe request (level 2), and sensor request (level 1). Following a descending priority order, the corresponding target checkers are matched for GPU request 1, PCIe request 2, PCIe request, and sensor request based on the traffic information from multiple checkers.

[0109] In some embodiments, step 204 may include:

[0110] Sub-step 2041: For any memory access request, compare the amount of cached data in the queues of multiple checkers through the arbitration node;

[0111] Sub-step 2042: The arbitrator node selects the checker with the lowest amount of cached data in the queue as the target checker and forwards the memory access request to the target checker.

[0112] In this embodiment of the application, the traffic information includes the amount of cached data in the queue.

[0113] In one possible implementation, each checker periodically reports load information to the arbitration node, such as the amount of cached data in the queue and processing progress. For example, it reports the current amount of cached data in the queue once every clock cycle.

[0114] In another possible implementation, when the arbitration node matches a checker for each request, it proactively sends a query signal to all checkers to obtain the amount of cached data in the queue reported by each checker. For example, each checker integrates a counter to count the current amount of cached data in the queue. The arbitration node reads the counter value to obtain the amount of cached data in the queue of each checker, and then determines which checker is less busy, thus achieving load balancing.

[0115] For example, for the first request (GPU request 1, level 3), query the traffic information of all inspectors and select inspector A with the lowest queue cache size as the target inspector; for the second request (GPU request 2, level 3), query the traffic information of all inspectors again. Since the load of inspector A has increased slightly at this time, select inspector B with the lowest queue cache size as the target inspector; for the third request (PCIe request, level 2), query the traffic information of all inspectors and select inspector C with the lowest queue cache size as the target inspector; for the fourth request (sensor request, level 1), query the traffic information of all inspectors. Since the request of inspector A has been processed and the load has decreased at this time, select inspector A with the lowest queue cache size as the target inspector.

[0116] The above technical solution uses an arbitration node to select the checker with the lowest amount of cached data in the queue as the target checker, while checkers with idle status perform permission verification. This avoids blocking caused by a single checker handling multiple requests at once, and is conducive to achieving load balancing of checkers.

[0117] For example, Figure 6 This is a schematic diagram illustrating the interconnection of an input / output bridge and a checker via an arbitration node, as provided in an embodiment of this application. See also... Figure 6 The arbitration node interconnects m IO bridges and n checkers. Figure 6 Bridge port 0, bridge port 1... bridge port m are the ports of the IO bridge, and each bridge port corresponds to an independent queue. Memory access requests received by each bridge port are first cached in the corresponding queue to avoid requests from multiple ports being directly mixed. Figure 6 The checker ports 0 through n represent the checker ports, each corresponding to an independent queue. Memory access requests forwarded by the arbitration node are first stored in the corresponding checker's queue, awaiting sequential verification by the checker. A counter in each checker queue is used to count the amount of cached data currently in the queue. The arbitration node reads the counter value to determine which checker is less busy, thus achieving load balancing.

[0118] In this embodiment, the total processing capacity of the Checker queue is less than the instantaneous peak request volume of the Bridge queue. That is, Checker_queue_total <= bridge_queue_instant.

[0119] It's important to note that each Checker's hardware logic has a fixed limit on the number of requests it can process per second. The more requests in the Checker queue, the longer the queuing and verification time for individual requests, leading to an increase in overall response latency. Theoretically, the total processing capacity of the checker queue should be greater than or equal to the theoretical instantaneous peak value of the bridge queue; otherwise, it may slow down system response. Especially when m and n are large, the processing capacity of a single checker will be far less than the total number of requests on the uplink bridge request port. Furthermore, the more requests queued in the checker queue, the later the checker will return results. If this exceeds the bridge cache limit, it will impact system performance.

[0120] In some embodiments, the memory access unit adopts a multi-region architecture, including multiple independent regions. Sub-step 2042 includes:

[0121] Sub-step 20421: When a memory access request arrives at the arbitration node in any region, query the amount of cached data in the first queue of the checker in the same region through the root query of the arbitration node.

[0122] Sub-step 20422: If the amount of cached data in the first queue is greater than the preset data amount threshold, query the amount of cached data in the second queue of the checker in the adjacent area through the arbitration node.

[0123] Sub-step 20423: If the amount of cached data in the second queue is greater than the data amount threshold, query the amount of cached data in the third queue of all checkers in the memory protection unit through the arbitration node.

[0124] Sub-step 20424: Based on the amount of cached data in the third queue, the arbitration node determines the target checker from all checkers and forwards the memory access request to the target checker.

[0125] In this embodiment, in the multi-region architecture memory access unit, each region is a relatively independent memory access processing unit. Each region includes at least one input / output bridge and at least one checker. At least one region deploys an arbitration node for forwarding memory access requests. The checker within a region has the lowest access latency but limited processing capacity; the checkers in adjacent regions have the next lowest latency; and the checker across all regions has the highest latency but the most abundant resources.

[0126] In one possible implementation, after sub-step 20421, the memory access method may further include: if the amount of cached data in the first queue is less than or equal to the data amount threshold, selecting the checker with the lowest amount of cached data in the queue from the checkers in the same region through an arbitration node as the target checker.

[0127] In one possible implementation, after sub-step 20422, the memory access method may further include: if the amount of cached data in the second queue is less than or equal to the data amount threshold, selecting the checker with the lowest amount of cached data in the queue from all checkers through an arbitration node as the target checker.

[0128] In one possible implementation, sub-step 20423 may include: selecting the checker with the lowest amount of cached data in the queue from the checkers in the adjacent region through the arbitration node as the target checker.

[0129] In one possible implementation, each checker's queue has a built-in counter to count the number of currently cached requests. The arbitration node reads the counter value through a distributed query bus or a multi-level routing query interface to determine the amount of cached data in the first queue, the second queue, or the third queue.

[0130] In one possible implementation, the arbitration node has a built-in cross-region routing table that determines the forwarding path with the lowest latency based on the target inspector's region ID and inspector ID, thus avoiding path congestion in cross-region transmission.

[0131] In one possible implementation, the data volume threshold is dynamically adjusted according to different scenarios. For example, the data volume threshold may be 8 requests, or it may be 80% of the maximum cached data volume.

[0132] Through the above technical solution, the arbitration node is equipped with a multi-level routing mechanism. When the load of the checkers in the same area is high, the arbitration node can query the adjacent areas and the global checkers, perform multiple routing operations, and forward the memory access requests to the low-load checkers. This achieves balanced optimization of system bus query traffic and reduces the possibility of blockage caused by a sudden increase in regional traffic.

[0133] Step 205: The arbitration node forwards multiple memory access requests to the target checker corresponding to each memory access request in descending order of priority.

[0134] In one possible implementation, the arbitration node forwards each request sequentially to its matching target checker according to the sorted queue order, so that low-priority requests can only be forwarded after all higher-priority requests have been forwarded.

[0135] For example, the arbitration node first forwards GPU request 1 to inspector A, then GPU request 2 to inspector B, then PCIe request to inspector C, and finally sensor request to inspector A, ensuring that high-priority requests are always executed first.

[0136] The above technical solution uses the priority of multiple input / output bridges as the priority of multiple memory access requests, eliminating the need to configure priorities for individual requests and simplifying scheduling logic. Secondly, when multiple input / output bridges send concurrent requests, they are sorted from highest to lowest priority. Based on the traffic information of multiple checkers, a corresponding target checker is matched for each memory access request, achieving load balancing of checkers and improving their resource utilization. Finally, multiple memory access requests are forwarded to the target checker corresponding to each memory access request in descending order of priority, ensuring that high-priority requests are processed first and are not blocked by low-priority requests.

[0137] In some embodiments, after step 205, the memory access method described above may further include:

[0138] Sub-step A1: Select the target input / output bridge with the lowest priority from multiple input / output bridges through the arbitration node;

[0139] Sub-step A2: Select the earliest initiated target memory access request from the unallocated target checker requests initiated by the arbitration node from the target input / output bridge;

[0140] Sub-step A3: Calculate the waiting time between the moment when the target input / output bridge initiates the target memory access request and the current moment;

[0141] Sub-step A4: If the waiting time exceeds the timeout threshold, increase the priority of the target input / output bridge through the arbitration node.

[0142] In this embodiment, after the target memory access request is processed, the original priority of the target input / output bridge is restored to prevent low-priority services from preempting the resources of high-priority services at once.

[0143] In one possible implementation, the arbitration node traverses all I / O bridges that initiate requests, and selects the I / O bridge with the lowest current priority based on a preset priority list to obtain the target input / output bridge.

[0144] In one possible implementation, the arbitration node queries the request queue of the target input / output bridge, filters out requests that have been initiated but not assigned to a checker, selects the request with the earliest initiation time, and obtains the target memory access request.

[0145] In one possible implementation, the arbitration node reads the initiation time of the target request and obtains the current system time, calculates the difference between the initiation time and the current system time, and obtains the waiting time.

[0146] For example, if the target request is initiated at time T1 = 100ns and the current time is T = 300ns, then the waiting time is 200ns.

[0147] In one possible implementation, the waiting time is compared with a preset timeout threshold; if the waiting time is less than or equal to the timeout threshold, the original priority is maintained; if the waiting time is greater than the timeout threshold, the priority of the target input / output bridge is increased through the arbitration node, so that subsequent requests initiated by the target input / output bridge can obtain a higher scheduling priority.

[0148] In one possible implementation, the priority of the target input / output bridge can be increased by arbitrating the node, which may include increasing the priority by 1 level for each timeout, or directly increasing it to medium priority.

[0149] For example, if the waiting time is 1.1 milliseconds (ms) and the timeout threshold is 1 ms, then the target input / output bridge priority will be increased by 1 level since 1.1 ms > 1 ms.

[0150] For example, if the waiting time is 201 nanoseconds (ns) and the timeout threshold is 200ns, then since 201ns > 200ns, the priority of the target input / output bridge will be increased from level 0 to level 2.

[0151] By implementing the above technical solution, a low-priority watchdog mechanism is set up to monitor the waiting time of low-priority input / output bridge requests. If the waiting time exceeds the timeout threshold, the priority of the target input / output bridge is increased to prevent low-priority requests from being unable to be processed for a long time.

[0152] Step 206: Verify the memory access permissions of the external device through the target checker, obtain the check result, and return the check result to the input / output bridge through the arbitration node.

[0153] The method for this step has been explained in step 103 above, and will not be repeated here.

[0154] Figure 7 This is a flowchart illustrating a method for verifying memory access permissions of an external device, as provided in an embodiment of this application. See also... Figure 7 Step 206 may include steps 301 to 303.

[0155] Step 301: Extract address information and identity identifier from memory access requests using the target inspector.

[0156] In this embodiment, the target inspector receives a standard access request that has been standardized by the input / output bridge and forwarded by the arbitration node in a unified format. The identity identifier is obtained based on the request identifier and device identifier corresponding to the memory access request; for example, the identity identifier is rrid.

[0157] In some embodiments, a memory access request includes a read operation and a write operation to a specified address in memory.

[0158] In some embodiments, a memory access request may be a secure access to memory, or it may be generated by an external device after being compromised by malware.

[0159] In some embodiments, the address field in the bus signal is extracted by combinational logic; the bus channel activation status is determined by a signal selector to obtain the identity identifier.

[0160] In some embodiments, before step 301, the memory access method further includes: reading the preset info register and hwcfg register in the SoC to obtain configuration information such as system version and hardware implementation specifications, and determining the permission verification rules of the checker based on the configuration information.

[0161] In one possible implementation, there may be multiple checkers in the same SoC, and each checker needs to be configured with separate permission verification rules.

[0162] Step 302: The target checker queries the preset permission data table based on the address information and identity identifier to determine whether the memory access request hits the permission data table.

[0163] In some embodiments, the permission data table stores multiple memory entries; each memory entry represents a sub-memory region within an accessible memory region and includes the address range and read / write permission configuration of the sub-memory region.

[0164] In some embodiments, memory entries are divided by the driver layer program and stored in the corresponding data structure.

[0165] In some embodiments, if the address information and identity identifier meet preset hit conditions, the target checker determines that the memory access request hits the permission data table; if the address information and identity identifier do not meet the hit conditions, the target checker determines that the memory access request does not hit the permission data table; wherein, the hit conditions include: the read / write permissions of the memory entry match the identity identifier of the memory access request, and the address information of the memory access request falls within the address range of the memory entry.

[0166] In some embodiments, the permission data table includes a first data table and a second data table. Step 302 includes:

[0167] Sub-step 3021: The target inspector queries the first data table based on the address information and identity identifier;

[0168] Sub-step 3022: If the memory access request does not hit the first data table, the target checker queries the second data table based on the address information and identity to determine whether the memory access request hits the second data table.

[0169] Sub-step 3023: If the memory access request hits the first data table and / or the second data table, the memory access request hits the permission data table.

[0170] The first data table is a cache table, which stores at least one memory entry that has been hit by a historical memory access request; the second data table is a global rule table, which stores all memory entries in the on-chip system.

[0171] In one possible implementation, when there is a first target data entry in the first data table that matches the memory access request, it indicates that the memory access request has hit the first data table. The matching of the memory access request with the first target data entry includes: the identity identifier (rrid) recorded in the first target data entry is consistent with the identity identifier (rrid) of the external device that issued the memory access request, and the memory address range corresponding to the memory entry of the first target data entry includes the target address accessed by the memory access request.

[0172] In one possible implementation, if the first target data entry does not exist, it indicates that the memory access request did not hit the first data table, and sub-step 3023 needs to be executed to further determine whether the memory address accessed by the memory access request is valid by querying the second data table.

[0173] For example, the first data table storage is set up in the IO bridge as a TLB lookup unit. The TLB lookup unit is a small table stored in the IO bridge that stores recently accessed addresses and permissions. In this way, when the query request on the bridge is relatively simple or highly localized, the result can be obtained directly from the bridge's TLB, resulting in faster query results and reducing the time spent on arbitrator forwarding and checker querying.

[0174] By using the above technical solution, storing at least one memory entry that has been hit by a historical memory access request in the first data table can quickly filter out some memory access requests, reduce the number of memory access requests that need to be verified for permissions, and shorten the total time required to process memory access requests.

[0175] In some embodiments, the second data table includes a first sub-data table, a second sub-data table, and a third sub-data table. Sub-step 3023 includes:

[0176] Sub-step 30231: If the memory access request does not hit the first data table, the target checker queries the first sub-data table, the second sub-data table, and the third sub-data table sequentially based on the address information and identity identifier.

[0177] Sub-step 30232: If the first sub-data table, the second sub-data table, and the third sub-data table are hit in sequence, the target checker determines that the memory access request hits the second data table.

[0178] The first sub-data table records the correspondence between external devices that can issue memory access requests and memory domains; the second sub-data table records the correspondence between accessible memory segments and memory entries; and the third sub-data table represents the address range and read / write permissions corresponding to the memory entry.

[0179] In this embodiment of the application, the first sub-data table may be a source memory domain table (SRCMD table), wherein each data entry of the first sub-data table is used to record the correspondence between an external device (Source) that can issue a memory access request and all memory domains (MD) of the external device.

[0180] In some embodiments, in the first sub-data table (SRCMD table), the identity identifier (rrid) of the external device corresponds to the memory domain (srcmd[rrid]), and srcmd[rrid] represents all accessible memory regions of the external device with the identity identifier rrid.

[0181] In this embodiment of the application, the second sub-data table may be a memory domain configuration table (MDCFG table). Each data entry in the second sub-data table (MDCFG table) is used to record the correspondence between memory domains and memory entries. The memory domains that the external device with the identity identifier rrid0 can access can be determined through the md value of the memory domain.

[0182] The md value is a set of bit values ​​that indicate which memory domains an external device can access. For example, 1 indicates that the memory domain corresponding to the bit is accessible to the external device, while 0 indicates that the memory domain corresponding to the bit is inaccessible to the external device.

[0183] In this embodiment of the application, the third sub-data table can be a memory entry table; each data entry in the third sub-data table records a range of memory addresses, which has consistent read and write permissions and is the smallest detection unit in permission verification, i.e., a memory entry.

[0184] It should be noted that the memory address ranges corresponding to different memory entries can overlap; understandably, each memory entry defines a memory protection rule, which specifies which external devices can access it, which memory address ranges can be accessed, and which operations are allowed to be performed on these memory address ranges.

[0185] In some embodiments, if a memory access request fails to hit at least one of the first sub-data table, the second sub-data table, and the third sub-data table, it indicates that the memory access request does not meet the conditions for permission verification and can be directly determined as a permission failure.

[0186] By using the above technical solution, and by querying the three sub-tables included in the second data table, it can be determined whether the memory segment accessed by the memory access request is included in the accessible memory segment of the external device that issued the memory access request, thereby performing permission verification of the external device and determining whether it is a safe memory access behavior.

[0187] In some embodiments, after sub-step 3023, the memory access method further includes:

[0188] Sub-step 3024: If a memory access request hits the second data table, the new memory entry hit by the memory access request is added to the first data table by the target checker.

[0189] Sub-step 3025: If the first data table has reached the preset capacity limit, replace the data entry in the first data table that has been hit the least with a new memory entry; wherein, the first data table is empty when it is initialized.

[0190] In this embodiment of the application, the content stored in the first data table can be dynamically changed, that is, the first data table stores a fixed number of memory entries.

[0191] In this way, based on the different access patterns of memory entries in historical memory access requests, new memory entries can be used to replace the memory entries that are hit the least, thereby ensuring that the memory entries stored in the first data table are all the most recently accessed memory entries.

[0192] Step 303: If the memory access request hits the permission data table, the target checker generates a check result indicating that the external device has passed the permission verification, and returns the check result to the input / output bridge through the arbitration node.

[0193] In this embodiment, the target checker first returns the check result to the arbitrator, and the arbitrator node returns the check result to the corresponding input / output bridge.

[0194] In some embodiments, if a memory access request matches the permission data table, it is determined whether the read / write permissions of the memory entry match the transaction type of the memory access request; if the read / write permissions of the memory entry match the transaction type of the memory access request, it is determined that the memory access request passes the permission check; if the read / write permissions of the memory entry do not match the transaction type of the memory access request, it is determined that the memory access request fails the permission check.

[0195] In some embodiments, if the read / write permissions of a memory entry match the transaction type of a memory access request, the identity of the memory access request is validated. If the identity passes the validation, the memory access request is determined to have passed the permission verification; otherwise, the memory access request is determined to have failed the permission verification.

[0196] By using the above technical solution, setting up a permission data table to verify the permissions of access requests from external devices is beneficial for quickly verifying the permissions of memory access requests, improving the speed of processing memory access requests, and thus reducing the time overhead in the memory access process while ensuring memory access security.

[0197] Step 207: If the inspection result indicates that the external device has passed the permission verification, allow the memory access request through the input / output bridge so that the external device can access the memory through the system-on-chip bus.

[0198] In this embodiment of the application, the Outstanding protocol in the AXI protocol allows the upstream master device to initiate multiple requests in succession before receiving the response to the previous request. The downstream slave device caches and processes the requests according to the request ID (ARID / AWID) and finally returns the response according to the request ID.

[0199] For example, if the inspection results indicate that the external device has passed the permission verification, the slave port and master port of the bridge are transparently transmitted, allowing the upstream and downstream devices connected through the bridge to communicate directly to resolve AXI protocol issues, including out-of-order issues and outstanding issues.

[0200] Step 208: If the inspection result indicates that the external device has failed the permission verification, perform interrupt error handling and data error handling operations through the input / output bridge.

[0201] For example, interrupt error handling and data error handling operations are stored in the capture register. When an illegal transaction is detected, the hardware reads the configuration of this register and executes the corresponding error handling.

[0202] In some embodiments, step 208 includes:

[0203] Sub-step 2081: If the check result is that the external device fails the permission verification, the context information of the memory access request is recorded through the input / output bridge, and an interrupt signal is sent to the processor of the on-chip system to notify the processor to handle the illegal access.

[0204] Sub-step 2082: If the identity of the memory access request is read data, return a null value to the external device through the input / output bridge;

[0205] Sub-step 2083: If the memory access request is identified as writing data, terminate the memory access request data write operation through the input / output bridge.

[0206] In this embodiment of the application, when a memory access request fails the permission check, it indicates that the memory access request is performing an unsafe memory access behavior and the memory access request is illegal. In this case, a memory access error will be triggered, and the corresponding error handling process will be triggered.

[0207] In one possible implementation, the input / output bridge has a built-in illegal access log register that writes the context information of illegal requests into the register.

[0208] In one possible implementation, the input / output bridge sends an illegal memory access interrupt signal to the processor (CPU) via the SoC's interrupt controller.

[0209] In one possible implementation, if the memory access request is identified as read data, the read data channel of the input / output bridge returns RDATA=0x0000_0000 (null value), and RRESP=SLVERR (slave error) is set at the same time.

[0210] In one possible implementation, if the memory access request is identified as write data, the WDATA of the write data channel is intercepted by the input / output bridge and not forwarded downstream.

[0211] In this way, if the check result shows that the external device has failed the permission verification, the error handling process is executed to prevent memory data from being illegally stolen and to protect the security of memory data.

[0212] In some embodiments, after step 208, the memory access method further includes:

[0213] Sub-step 209: If the inspection result indicates that the external device has failed the permission verification, mark the memory access request as an illegal memory access request;

[0214] Sub-step 210: Extract the request identifier of illegal memory access request through the input / output bridge, and identify the entire group of transmission requests with the same request identifier as related requests;

[0215] Sub-step 211: Handle packet loss of relevant requests through the input / output bridge.

[0216] In this embodiment of the application, in order to distinguish it from the AXI bus protocol in the prior art, sub-steps 209 to 211 are also referred to as "pseudo-AXI bus protocol".

[0217] In one possible implementation, group-related requests may include: multiple shots of data from the same burst transmission, outstanding concurrent requests from the same device, etc.

[0218] In one possible implementation, packet loss handling may include: not forwarding the relevant request to the arbitration node or memory, not caching the relevant request, and returning an error message.

[0219] In one possible implementation, after sub-step 210, the memory access method further includes: returning an error response to the relevant request via an input / output bridge.

[0220] In one possible implementation, after sub-step 211, the memory access method further includes: responding to an interrupt by the processor, reading the illegal access log register of the input / output bridge to obtain the context information of the illegal memory access request; analyzing the reason for the illegality based on the context information of the illegal memory access request; and informing the external device that initiated the illegal memory access request to retransmit the legal request through protocol layer interaction.

[0221] Figure 8 This is a schematic diagram of a forwarding logic for an error response in existing technology. See also... Figure 8 In the AXI bus protocol, devices are divided into master devices and slave devices. The master device is the device that actively initiates memory access requests; the slave device is the device that receives and responds to the requests.

[0222] For example, taking a read channel as an example, the forwarding logic of error responses in the prior art is as follows:

[0223] 1. When an external device initiates a request, the Slave port of the input / output bridge sequentially receives four ID0 read requests initiated by the external device, including ID0a, ID0b, ID0c, and ID0d; these four read requests belong to the same ID0 group.

[0224] 2. Each request is forwarded to the checker for verification, specifically including: ID0a: verification passed (Pass); ID0b: verification passed (Pass); ID0c: verification failed (Fail); ID0d: verification passed (Pass).

[0225] 3. ID0a, ID0b, and ID0d that pass the verification are forwarded to the master device, which then initiates a read request to the downstream device (such as memory). After the downstream device completes the processing, it returns a normal response (Rspok), and the master device then sends the response back to the Slave port of the input / output bridge.

[0226] 4. ID0c that fails verification will not be forwarded to the master device; according to the protocol specification, the input / output bridge directly generates an error response (Rsperror) for ID0c and sends the response back to the Slave port of the input / output bridge.

[0227] 5. The Slave ports of the input / output bridge send responses back to the external devices in the order the requests are initiated, specifically including: ID0a: Rspok; ID0b: Rspok; ID0c: Rsperror; ID0d: Rspok.

[0228] For example, see Figure 9 Taking the read channel as an example, the error response forwarding logic provided in this application embodiment is as follows:

[0229] 1. The Slave port of the input / output bridge initiates 4 read requests (ar requests) for ID0.

[0230] 2. Each request is forwarded to the checker for verification, specifically including: ID0a: verification passed (Pass); ID0b: verification passed (Pass); ID0c: verification failed (Fail); ID0d: verification passed (Pass).

[0231] 3. After ID0a, ID0b, and ID0d pass the verification, they are forwarded to the master device, which then initiates a read request to the downstream device. After the downstream device completes the processing, it returns a response to the r channel. The mst port marks these responses as Rspok and then forwards them to the Slave port of the input / output bridge.

[0232] 4. If ID0c verification fails, the request is not forwarded to the master device. At the same time, the request identifier of the illegal memory access request is extracted through the input / output bridge. The request identifier is ID0. Rsperror (error response) is returned for the request of ID0 group, and this error response will be associated with the response process of the entire group of ID0 requests.

[0233] As can be seen, in this embodiment of the application, if the inspection result indicates that the external device has failed the permission verification, an error response logic different from the standard AXI protocol will be triggered, and the process of returning the error response is different from the standard AXI protocol. Figure 9 The dashed box in the middle represents the aggregated processing of error responses. In this embodiment of the application, when ID0c verification fails, the response order of ID0b and ID0c is reversed, causing the data of ID0b to be unavailable, which in turn causes the entire group of data with the request identifier ID0 to be unavailable.

[0234] It should be noted that transactions with the same request ID must be responded to in order. If the previous request for any request ID is invalid, the IO Bridge will continue to block subsequent requests with that request ID until the upstream has processed the error and reset, thus avoiding disorder of the order of transactions with the same ID.

[0235] Understandably, when a transmission error occurs, because an error message is returned immediately, the error message returned to the upstream during multiple transmissions is not the error response for the current transmission, but it will definitely be the error response for the current group. In fact, once a security check is triggered, it already means that this data transmission is illegal, so the requests to be transmitted in the same group to which it belongs can also be considered illegal.

[0236] By implementing the above technical solutions and setting up an error response mechanism for relevant requests, system performance is improved and the resource overhead of maintaining outstanding functions is reduced.

[0237] In summary, this application proposes a distributed IOPMP architecture for large-scale SoC systems, which can reduce hardware resource overhead, increase maximum operating frequency, and improve bus throughput. Secondly, through a bridge-to-checker arbitration forwarding mechanism based on flow control, query requests can be reasonably allocated to different checkers, thus rationally utilizing hardware resources. Finally, an error response mechanism for related requests is set up, which improves system performance and reduces hardware overhead.

[0238] Figure 10 This is a flowchart of another memory access method provided in an embodiment of this application, which includes the following steps.

[0239] Step 401: Initialize the memory protection unit system.

[0240] In this embodiment, the version information of the hardware system is detected, and the IOPMP system is initialized and configured according to the hardware capabilities.

[0241] Step 402: The device sends a request to the input / output bridge.

[0242] In this embodiment of the application, the device is equivalent to the external device in the aforementioned method.

[0243] The method for this step has been explained in step 101 above, and will not be repeated here.

[0244] Step 403: The input / output bridge sends the request to the arbitrator.

[0245] In this embodiment of the application, the arbitrator is equivalent to the arbitration node in the aforementioned method.

[0246] The method for this step has been explained in step 101 above, and will not be repeated here.

[0247] Step 404: The arbitrator forwards the request to the inspector.

[0248] The method for this step has been explained in step 102 above, and will not be repeated here.

[0249] Step 405: The inspector receives the request.

[0250] The method for this step has been explained in step 102 above, and will not be repeated here.

[0251] Step 406: Query the page table.

[0252] In this embodiment of the application, the page table refers to the permission data packet, and querying the page table is equivalent to performing permission verification on the external device in the aforementioned method.

[0253] Step 407: Determine if the permissions are valid. If yes, proceed to step 409; otherwise, proceed to step 408.

[0254] The method for this step has been described in steps 301 to 303 above, and will not be repeated here.

[0255] Step 408, Error Capture and Interruption Handling.

[0256] The method for this step has been explained in step 208 above, and will not be repeated here.

[0257] Step 409: The check results are returned to the input / output bridge.

[0258] The method for this step has been explained in step 103 above, and will not be repeated here.

[0259] Step 410: The input / output bridge processes the data based on the results.

[0260] The method for this step has been explained in step 207 above, and will not be repeated here.

[0261] In summary, this application proposes a distributed IOPMP architecture for large-scale SoC systems, which provides a superior solution in terms of reducing hardware resource overhead, increasing maximum operating frequency, and improving bus throughput. Secondly, based on a flow control-based bridge-to-checker arbitration mechanism, query requests are rationally allocated to different checkers, thus efficiently utilizing hardware resources. Finally, when a checker returns an error, bus error information is returned directly instead of waiting, reducing hardware overhead.

[0262] Figure 11 This is a block diagram of a memory access device provided in an embodiment of this application, such as... Figure 11 As shown, it is applied to a memory protection unit, which includes at least one arbitration node, multiple input / output bridges, and multiple checkers. The arbitration node is deployed between the multiple input / output bridges and the multiple checkers. The input / output bridges are used to connect external devices to the bus of the on-chip system. The memory access 500 includes the following modules.

[0263] The request receiving module 501 is used to receive memory access requests sent by external devices through the input / output bridge and send them to the arbitration node;

[0264] The traffic arbitration module 502 is used to determine the target inspector from multiple inspectors based on the traffic information of multiple inspectors through the arbitration node, and forward the memory access request to the target inspector.

[0265] The permission calibration module 503 is used to verify the memory access permissions of external devices through the target checker, obtain the check results, and return the check results to the input / output bridge through the arbitration node; the check results are used to characterize whether the external device has passed the permission verification.

[0266] Optionally, there may be multiple memory access requests, and the traffic arbitration module 502 includes:

[0267] The priority determination submodule is used to obtain the preset priorities of multiple input / output bridges through an arbitration node when there are multiple input / output bridges initiating multiple memory access requests, and to use the priorities of the multiple input / output bridges as the priorities of the multiple memory access requests.

[0268] The checker matching submodule is used to match the corresponding target checker for each memory access request in descending order of priority by the arbitration node, based on the traffic information of multiple checkers.

[0269] The request forwarding submodule is used to forward multiple memory access requests to the target checker corresponding to each memory access request in descending order of priority through the arbitration node.

[0270] Optionally, the memory access 500 also includes:

[0271] The first selection module is used to select the target input / output bridge with the lowest priority from multiple input / output bridges through an arbitration node;

[0272] The second selection module is used to select the earliest initiated target memory access request from the unallocated target checker requests initiated from the target input / output bridge through the arbitration node.

[0273] The duration calculation module is used to calculate the waiting time between the moment when the target input / output bridge initiates the target memory access request and the current moment;

[0274] The priority adjustment module is used to increase the priority of the target input / output bridge through the arbitration node when the waiting time exceeds the timeout threshold.

[0275] Optionally, traffic information includes the amount of cached data in the queue, and the checker matching submodule includes:

[0276] The cache comparison unit is used to compare the amount of cached data in the queues of multiple checkers through the arbitration node for any memory access request.

[0277] The checker determination unit is used to select the checker with the lowest amount of cached data in the queue as the target checker through the arbitration node, and forward the memory access request to the target checker.

[0278] Optional, the permission calibration module 503 includes:

[0279] The extraction submodule is used to extract address information and identity information from memory access requests through the target inspector; the identity information is obtained based on the request identifier and device identifier corresponding to the memory access request.

[0280] The query submodule is used to query the preset permission data table based on the address information and identity identifier through the target checker to determine whether the memory access request hits the permission data table;

[0281] The generation submodule is used to generate a check result indicating that the external device has passed the permission verification when the memory access request hits the permission data table, through the target checker, and return the check result to the input / output bridge through the arbitration node.

[0282] Optionally, the permission data table includes a first data table and a second data table, and the query submodule includes:

[0283] The first data table query unit is used to query the first data table based on address information and identity identifier through the target checker;

[0284] The second data table query unit is used to query the second data table based on address information and identity identifier by the target checker when the memory access request does not hit the first data table, in order to determine whether the memory access request hits the second data table.

[0285] The hit determination unit is used to determine if the memory access request hits the permission data table when the memory access request hits the first data table and / or the second data table.

[0286] The first data table is a cache table, which stores at least one memory entry that has been hit by a historical memory access request; the second data table is a global rule table, which stores all memory entries in the on-chip system.

[0287] Optionally, the second data table includes a first sub-data table, a second sub-data table, and a third sub-data table. In the event that a memory access request does not hit the first data table, the second data table query unit includes:

[0288] The query sub-unit is used to sequentially query the first, second, and third sub-data tables based on address information and identity identifiers when a memory access request does not hit the first data table.

[0289] The sub-unit is determined by the target checker to determine that the memory access request hits the second data table when the first, second, and third sub-data tables are hit in sequence.

[0290] The first sub-data table records the correspondence between external devices that can issue memory access requests and memory domains; the second sub-data table records the correspondence between accessible memory segments and memory entries; and the third sub-data table represents the address range and read / write permissions corresponding to the memory entry.

[0291] Optionally, the request receiving module 501 includes:

[0292] The parameter extraction submodule is used to receive memory access requests sent by external devices through the input / output bridge and extract parameter information from the memory access requests; the parameter information includes address information, transaction type, request identifier, and device identifier;

[0293] The parameter integration submodule is used to integrate parameter information according to the protocol format of the on-chip system bus through the input / output bridge, obtain a standard access request, and send the standard access request to the arbitration node.

[0294] Optionally, the memory access 500 also includes:

[0295] The request release module is used to release memory access requests through the input / output bridge when the inspection result indicates that the external device has passed the permission verification, so that the external device can access memory through the on-chip system bus.

[0296] The error handling module is used to perform interrupt error handling and data error handling operations through the input / output bridge when the check result indicates that the external device has failed the permission verification.

[0297] Optionally, the memory access 500 also includes:

[0298] The request marking module is used to mark memory access requests as illegal memory access requests when the inspection result indicates that the external device has failed the permission verification.

[0299] The request determination module is used to extract the request identifier of illegal memory access requests through the input / output bridge, and to identify the entire group of transport requests with the same request identifier as related requests;

[0300] The request packet loss module is used to handle packet loss of relevant requests through the input / output bridge.

[0301] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0302] Figure 12 This is a structural block diagram of an electronic device according to an exemplary embodiment. For example... Figure 12 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the steps of the simulation stimulus data extraction method of the graphics processor in the foregoing embodiment.

[0303] This application also provides a system-on-a-chip, which includes the aforementioned memory protection unit, memory access device or electronic device, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0304] This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described memory access method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0305] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0306] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described graphics processor simulation stimulus data extraction method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0307] This application also provides a computer program product, including a computer program that, when executed by a processor, implements a method for extracting simulation stimulus data of a graphics processor.

[0308] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0309] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0310] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0311] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0312] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0313] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0314] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0315] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A memory access method, characterized in that, An application is made to a memory protection unit, the memory protection unit including at least one arbitration node, multiple input / output bridges, and multiple checkers, the arbitration node being deployed between the multiple input / output bridges and the multiple checkers, the input / output bridges being used to connect external devices to the system-on-a-chip bus, the method comprising: The input / output bridge receives memory access requests sent by the external device and sends them to the arbitration node. The arbitration node determines the target checker from the multiple checkers based on the traffic information of the multiple checkers, and forwards the memory access request to the target checker. The target checker verifies the memory access permissions of the external device, obtains the check result, and returns the check result to the input / output bridge through the arbitration node; the check result is used to characterize whether the external device passes the permission verification. The memory access request is multiple. After the arbitration node determines the target checker from the multiple checkers based on the traffic information of the multiple checkers and forwards the memory access request to the target checker, the method further includes: When there are multiple input / output bridges initiating multiple memory access requests, the arbitration node selects the target input / output bridge with the lowest priority from among the multiple input / output bridges. The earliest initiated target memory access request is selected from the unallocated target checker requests initiated by the arbitration node from the target input / output bridge. Calculate the waiting time between the moment when the target input / output bridge initiates the target memory access request and the current moment; If the waiting time exceeds the timeout threshold, the priority of the target input / output bridge is increased through the arbitration node.

2. The method according to claim 1, characterized in that, The step of determining the target inspector from the plurality of inspectors based on the traffic information of the plurality of inspectors through the arbitration node, and forwarding the memory access request to the target inspector, includes: When there are multiple input / output bridges initiating multiple memory access requests, the arbitration node obtains the preset priorities of the multiple input / output bridges, and uses the priorities of the multiple input / output bridges as the priorities of the multiple memory access requests; The arbitration node, in descending order of priority, sequentially matches each memory access request with a corresponding target checker based on the traffic information of the multiple checkers. The arbitration node forwards the multiple memory access requests to the target checker corresponding to each memory access request in descending order of priority.

3. The method according to claim 2, characterized in that, The traffic information includes the amount of cached data in the queue. The arbitration node, in descending order of priority, sequentially matches each memory access request to a corresponding target checker based on the traffic information of the multiple checkers, including: For any memory access request, the amount of cached data in the queues of the multiple checkers is compared through the arbitration node; The arbitration node selects the checker with the lowest amount of cached data in the queue as the target checker and forwards the memory access request to the target checker.

4. The method according to claim 1, characterized in that, The step of verifying the memory access permissions of the external device through the target checker, obtaining the check result, and returning the check result to the input / output bridge through the arbitration node includes: The target inspector extracts the address information and identity identifier from the memory access request; the identity identifier is obtained based on the request identifier and device identifier corresponding to the memory access request. The target inspector queries a preset permission data table based on the address information and the identity identifier to determine whether the memory access request matches the permission data table. When the memory access request hits the permission data table, the target checker generates a check result indicating that the external device has passed the permission verification, and the check result is returned to the input / output bridge through the arbitration node.

5. The method according to claim 4, characterized in that, The permission data table includes a first data table and a second data table. The step of querying the preset permission data table using the target checker based on the address information and the identity identifier to determine whether the memory access request matches the permission data table includes: The target inspector queries the first data table based on the address information and the identity identifier; If the memory access request does not hit the first data table, the target checker queries the second data table based on the address information and the identity identifier to determine whether the memory access request hits the second data table. If the memory access request hits the first data table and / or the second data table, the memory access request hits the permission data table; The first data table is a cache table, which stores at least one memory entry that has been hit by a historical memory access request; the second data table is a global rule table, which stores all the memory entries in the on-chip system.

6. The method according to claim 5, characterized in that, The second data table includes a first sub-data table, a second sub-data table, and a third sub-data table. The step of determining whether the memory access request hits the second data table by querying the second data table based on the address information and the identity identifier when the memory access request does not hit the first data table includes: If the memory access request does not hit the first data table, the target checker queries the first sub-data table, the second sub-data table, and the third sub-data table sequentially based on the address information and the identity identifier. If the first sub-data table, the second sub-data table, and the third sub-data table are hit in sequence, the target checker determines that the memory access request hits the second data table. In this system, each data entry in the first sub-data table records the correspondence between external devices that can issue memory access requests and memory domains; each data entry in the second sub-data table records the correspondence between accessible memory segments and memory entries; and each data entry in the third sub-data table represents the address range and read / write permissions corresponding to the memory entry.

7. The method according to claim 1, characterized in that, The step of receiving the memory access request sent by the external device through the input / output bridge and sending it to the arbitration node includes: The input / output bridge receives memory access requests sent by the external device and extracts parameter information from the memory access requests; the parameter information includes address information, transaction type, request identifier, and device identifier. The parameter information is integrated according to the protocol format of the on-chip system bus through the input / output bridge to obtain a standard access request, and the standard access request is sent to the arbitration node.

8. The method according to claim 1, characterized in that, The method further includes verifying the memory access permissions of the external device through the target checker, obtaining the check result, and returning the check result to the input / output bridge through the arbitration node. If the inspection result indicates that the external device has passed the permission verification, the memory access request is allowed through the input / output bridge, so that the external device can access the memory through the system-on-a-chip bus; If the inspection result indicates that the external device has failed the permission verification, interrupt error handling and data error handling operations are performed through the input / output bridge.

9. The method according to claim 8, characterized in that, After the external device passes the permission verification as indicated by the inspection result, and after performing interrupt error handling and data error handling operations through the input / output bridge, the method further includes: If the inspection result indicates that the external device has failed the permission verification, the memory access request will be marked as an illegal memory access request. The request identifier of the illegal memory access request is extracted through the input / output bridge, and the entire group of transmission requests with the same request identifier is identified as related requests; The relevant requests are processed for packet loss through the input / output bridge.

10. A memory protection unit, characterized in that, The memory protection unit includes at least one arbitration node, multiple input / output bridges, and multiple checkers. The arbitration node is deployed between the multiple input / output bridges and the multiple checkers. The input / output bridges are used to connect external devices to the on-chip system bus. The input / output bridge is used to receive memory access requests sent by the external device and send them to the arbitration node; there are multiple memory access requests. The arbitration node is used to determine the target inspector from the plurality of inspectors based on the traffic information of the plurality of inspectors, and forward the memory access request to the target inspector; The target checker is used to verify the memory access permissions of the external device, obtain the check result, and return the check result to the input / output bridge through the arbitration node; the check result includes whether the external device passes the permission verification. The arbitration node is further configured to, when there are multiple input / output bridges initiating multiple memory access requests, select the target input / output bridge with the lowest priority from the multiple input / output bridges through the arbitration node; select the earliest initiated target memory access request from the unallocated target checker requests initiated by the target input / output bridge through the arbitration node; calculate the waiting time between the time when the target input / output bridge initiates the target memory access request and the current time; and, if the waiting time exceeds a timeout threshold, increase the priority of the target input / output bridge through the arbitration node.

11. The memory protection unit according to claim 10, characterized in that, The memory access unit adopts a multi-region architecture, including multiple independent regions; each region includes at least one input / output bridge and at least one checker; At least one of the multiple regions deploys an arbitration node for forwarding the memory access requests; the number of arbitration nodes deployed in each region is determined based on the number of external devices connected to the region and the expected concurrency of the memory access requests.

12. A system-on-a-chip, characterized in that, Includes the memory protection unit as described in claim 10 or 11.

13. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the memory access method as described in any one of claims 1-9.

Images