Method and apparatus for hardware resource sharing in direct memory access controller

Abstract

A direct memory access controller (DMAC) includes a virtual channel, a physical channel, and a context manager. The virtual channel is configured to generate a flow control signal for executing a direct memory access (DMA) command. The physical channel includes read and write control logic to initiate data transmission from the source device to the destination device in accordance with the DMA command in response to the flow control signal. In one embodiment, a context manager includes: allocation logic configured to arbitrate between allocation requests from virtual channels and to allocate physical channels to selected virtual channels; and routing logic configured to route a flow control signal from the selected virtual channel to the allocated physical channel, and to route a status signal between the allocated physical channel and the selected virtual channel.

Description

BACKGROUND

[0001] In data processing systems, a direct memory access (DMA) controller enables the movement of blocks of data from a peripheral device to memory, from memory to a peripheral device, or from memory to memory without burdening a processor. The DMA controller can include multiple channels. Each DMA channel includes hardware that is programmed to generate one or more addresses, such as memory addresses or addresses of memory-mapped peripheral devices, and initiate read and write cycles.

[0002] When a peripheral device operates at a slow rate (e.g., compared to a processor), the associated DMA channel can operate at a fraction of its maximum capacity, resulting in inefficient use of hardware resources. BRIEF DESCRIPTION OF DRAWINGS

[0003] The drawings provide visual representations, which will serve to more fully describe the various representative embodiments, and can be used by those of ordinary skill in the art to better understand the representative embodiments disclosed and their inherent advantages. In the drawings, like reference numerals refer to corresponding or similar elements throughout.

[0004] Figure 1 is a block diagram of a data processing system including a direct memory access controller (DMAC) in accordance with various representative embodiments.

[0005] Figure 2 is a block diagram of a direct memory access controller (DMAC) in accordance with various representative embodiments.

[0006] Figure 3 is a block diagram of a virtual channel of a DMAC in accordance with various representative embodiments.

[0007] Figure 4 is a block diagram of a physical channel of a DMAC in accordance with various representative embodiments.

[0008] Figure 5 is a block diagram of a context manager of a DMAC in accordance with various representative embodiments.

[0009] Figure 6 is a block diagram of a DMA control logic block in accordance with various representative embodiments.

[0010] Figure 7 is a block diagram of a data bus interface (BIU) of a DMAC in accordance with various representative embodiments.

[0011] Figure 8 is a block diagram of a context bus interface (BIU) of a DMAC in accordance with various representative embodiments.

[0012] Figure 9 This is another block diagram of the physical channel of DMAC according to various representative implementation schemes.

[0013] Figure 10 It is a schematic diagram of reading and writing a finite state machine (FSM) according to various representative implementation schemes.

[0014] Figure 11 It is a block diagram of the context manager based on various representative implementation schemes.

[0015] Figure 12 This is another block diagram of the context manager based on various representative implementation schemes.

[0016] Figure 13 This is a schematic diagram of a contextual FSM for a physical channel based on various representative implementation schemes.

[0017] Figure 14 It is a schematic diagram illustrating the signal flow between the virtual channel and the physical channel according to various representative implementation schemes.

[0018] Figure 15A and Figure 15B Together, they form a flowchart of a virtual channel control (FSM) based on various representative implementation schemes.

[0019] Figure 16 These are example timing diagrams of channel operation based on various representative implementation schemes.

[0020] Figure 17 These are example timing diagrams of channel operation based on various representative implementation schemes.

[0021] Figure 18 These are example sequence diagrams based on various representative implementation schemes.

[0022] Figure 19 These are example sequence diagrams based on various representative implementation schemes.

[0023] Figure 20 This is another example sequence diagram based on various representative implementation schemes. Detailed Implementation

[0024] The various devices and apparatuses described herein provide mechanisms for sharing hardware resources in direct memory access (DMA) controllers.

[0025] While the disclosure is amenable to various forms of embodiments, there are described in detail herein specific embodiments with reference to the drawings, it being understood that the embodiments shown and described are intended as examples of implementing the principles of the disclosure and not intended to limit the disclosure to the specific embodiments shown and described. In the description herein, like reference numerals are used to describe the same, similar or corresponding parts in the several views of the drawings. For the sake of brevity and clarity, some of the figures described herein are repeated in the drawings.

[0026] DMA channels of a DMA controller (DMAC) are the core engines that support the data movement functionality. According to the present disclosure, the DMAC structurally divides the DMA channels into virtual channels (VCHs) and physical channels (PCHs). The virtual channels implement aspects of data transfer that are unique to each DMA channel, while the physical channels consist of logic and resources that are the same for each DMA channel. Specifically, one or more physical channels are shared among multiple virtual channels. The DMAC includes a context manager that controls the virtual channel allocation and deallocation of the physical channels. The virtual channels implement a control state machine that manages the lifetime of the DMA channels. The DMA channels can have peripheral triggered ports for autonomous command and flow control between the DMA and the peripheral. Each virtual channel has its own trigger control block that handles the corresponding external trigger interface.

[0027] From the perspective of the external software, there are only DMA channels. However, on the micro-architecture, the DMAC splits the channels into VCH / PCH pairs. VCH-X is always part of channel X and includes a state machine that tracks and controls the lifetime of the DMA commands that the channel should execute. PCH-Y is not always part of channel X, but can be allocated to channel X or any of the other DMA channels.

[0028] In one embodiment, the virtual channels also provide general purpose outputs (GPOs) for system level control, depending on the configuration.

[0029] In one embodiment, the physical channels implement read and write control logic, which can include burst calculation logic and pipelining. They can also implement command chaining logic for read command descriptors and, based on these, perform the necessary updates to the relevant registers in the PCH and / or VCH or context memory. Each physical channel can implement its own context fetch / save logic, as well as register reload logic used by commands that are set to automatically restore some registers to their initial values.

[0030] In one embodiment, the physical channels are connected to a bus interface unit (BIU) via, for example, a custom DMA transport interface, which acts as an arbiter between the physical channels operating in parallel and generates transfers on its bus interface upon request by the PCH. The data BIU arbitrates DMA data transfer requests or command descriptor read requests during a command link.

[0031] In one embodiment, the data BIU contains a data first-in-first-out (FIFO) buffer shared among the PCHs. While a FIFO could be incorporated in each physical channel, locating the FIFO in the data BIU avoids duplication and reduces the amount of logic circuitry.

[0032] "Context data" or "channel context" refers herein to any information that resides in a physical channel when it is allocated to a virtual channel and in context memory when a virtual channel does not have a physical channel allocated to it. This data includes architectural data and micro-architectural data. Software on an external device that programs and uses a DMA channel expects to be able to read or write specified control and status data. This data is referred to as architectural data. Architectural data is stored in registers that software writes when programming a channel and reads when polling channel status. Data stored in a physical channel is part of the context data. Micro-architectural data includes any data other than architectural data that the DMAC uses to implement the architectural behavior seen by the external device. For example, this can include counter values such as trigger block remaining counter values, some initial values, state machine states, error correction code (ECC) sums, etc.

[0033] When a given channel is allocated, its PCH context data is in the PCH. In the deallocated state, the context data for a given channel is saved to context memory, and all PCH modules contain context data for other channels.

[0034] A portion of the context data for each channel, referred to as the context for the channel, can be stored in context memory. This context memory can be external memory accessed via a context BIU. The context for a channel includes architectural and micro-architectural information based on which the channel operates and performs DMA transfers. Another portion of the channel context can be stored within the DMAC in a VCH register set. The context stored in context memory is either loaded or fetched into the PCH allocated to the VCH or written back (saved) when the VCH is deallocated.

[0035] While a single BIU can be shared for DMA data transfers and context data accesses, using separate BIUs reduces the bandwidth impact of moving context data between the PCH and context memory. In addition, this reduces bus contention and allows one physical channel to perform DMA transfers while the other physical channel saves or loads context data due to reassignment.

[0036] In one embodiment, the DMAC includes a control block that defines additional settings for each channel and selects the channel safety level. It can also collect global status information and interrupts from the virtual channels to make it easier to manage the entire DMA.

[0037] The DMAC can include a low power interface (LPI) control block that provides stall capability for the clock and handles power control.

[0038] Figure 1 is a block diagram of a data processing system 100 including a direct memory access controller (DMAC) 102 according to various representative embodiments. In addition to the DMAC 102, the system 100 includes one or more processors 104, a memory system 106, and a peripheral system 108. The memory system 106 can include one or more memories and associated memory controllers. The peripheral system 108 can include peripherals such as universal asynchronous receiver-transmitters (UARTs), serial peripheral interfaces (SPIs), inter-integrated circuit (I2C) ports or timers, and other peripherals that provide data input or output. The DMAC 102 provides fast memory-to-memory copy, peripheral-to-memory copy, memory-to-peripheral copy, and peripheral-to-peripheral capabilities on multiple channels.

[0039] In some embodiments, the components of the data processing system 100 are connected and managed via a bus system such as the Arm Limited's open standard Advanced Microcontroller Bus Architecture (AMBA ® For example, the bus system can include an advanced high-performance bus (AHB) for fast, low-latency transactions and an advanced peripheral bus (APB), which is a highly compact, low-power bus for configuration and low-bandwidth traffic. The APB supports low-bandwidth transactions for accessing configuration registers and low-bandwidth data traffic in peripherals. While the DMAC is described below with reference to AHB and APB, it will be appreciated that other bus architectures can be used without departing from the present disclosure. For example, the bus system can include an advanced extensible interface (AXI) bus for high-speed, low-latency transactions and an advanced peripheral bus (APB), which is a highly compact, low-power bus for configuration and low-bandwidth traffic. Figure 1In the illustrated embodiment, bus matrix 110 provides interconnection between different components. Bridge 112 bridges between the AHB of processor 104 and the APB of DMAC 102. This link is used to enable processor 104 to control DMAC 102 by, for example, writing to configuration registers. Bridge 114 bridges between the AHB of bus matrix 110 and the APB of the peripherals of peripheral system 108. Context memory 116, such as random access memory (RAM), is used to store context data (e.g., logic and memory values) for DMAC 102. In the illustrated embodiment, this is a dedicated memory accessed via a dedicated bus. In another embodiment, the context memory is a region in shared memory, accessed via bus matrix 110.

[0040] Completion of a transfer by DMAC 102 can be signaled to processor 104 via one or more interrupt signal lines 118.

[0041] DMAC 102 can include a first bus interface unit (BIU) to access devices of peripheral system 108 via an AHB bus architecture. In addition, a link 122 can be provided between DMAC 102 and the peripherals of peripheral system 108 to enable request and trigger sending.

[0042] Figure 2 is a block diagram of a direct memory access controller (DMAC) 102 in accordance with various representative embodiments. DMAC 102 provides fast memory-to-memory copy, peripheral-to-memory copy, memory-to-peripheral copy, and peripheral-to-peripheral capabilities on multiple channels, and can have configurations for different types of copy, scatter-gather, and incremental transfer.

[0043] The DMAC structurally divides the DMA channels into virtual channels (VCHs) 200 and one or more physical channels (PCHs) 202. The virtual channels implement aspects unique to each DMA channel, such as triggering and flow control, while the physical channels consist of logic circuitry and other resources that are the same for each DMA channel. In Figure 2 In the illustrated embodiment, DMAC 102 implements two physical channels (PCH0 and PCH1) that are shared among four virtual channels (VCH0, VCH1, VCH2, and VCH3). In general, multiple virtual channels share fewer physical channels. In one embodiment, the DMAC has 2 to 32 physical channels, and the number of virtual channels is a multiple (e.g., two, four, or eight times) of the number of physical channels.

[0044] Sharing of physical channels is controlled by the context manager 204. In one embodiment, a virtual channel requests access to a physical channel on request line 206. When the request is granted, the context manager signals the virtual channel on grant line 208. The context manager 204 controls the allocation and deallocation of virtual channels to physical channels.

[0045] The virtual channels 200 can include an interface to a trigger line 210 and provide the associated control logic for receiving peripheral trigger signals and sending triggers and other general purpose outputs (GPOs) for command and flow control between the DMAC and peripherals. The trigger interface can be used to control DMA channel operations interaction with other peripherals. An external peripheral or device can control the execution of DMA commands through the trigger input interface. The DMAC can also control external peripherals through its trigger output interface. The trigger input and trigger output interfaces are compatible with each other. Because of this compatibility, it is also possible to link two DMA channels together, either internally within the DMAC, or by linking multiple DMACs together. In addition to the hardware trigger interface, a software trigger interface can also be provided through the channel control registers, which can be programmed by an external device to generate a trigger input that enables the external device executing software to interact with the trigger and flow control.

[0046] Note that the virtual channels 200 are not abstract entities. Rather, they are implemented in hardware in the DMAC 102. The hardware is configured to generate memory and peripheral addresses to be transferred to the physical channels. A virtual channel cannot cause a DMA transfer without being allocated to a physical channel. The virtual channels can include context finite state machine (FSM) logic that tracks its own allocation state and handles interactions with the context manager.

[0047] The physical channels (PCHs) 202 implement read and write control logic to generate read and write data transfer requests. Each physical channel is allocated to one virtual channel at a time.

[0048] Commands are transferred to a data bus interface unit (BIU) 214 that arbitrates between DMA data transfer requests or command descriptor read requests during command linking. The selected request is placed on the AHB bus and transferred to the bus matrix 110 for routing. A context BIU 216 is used to access the context memory 116.

[0049] In one embodiment, the DMAC 102 includes a low power interface (LPI) module 218 that provides support for both clock and power control via a clock control channel (CLK CNTL) and a power control channel (PWR CNTL).

[0050] The DMA control logic block 220 controls the global operation of the DMAC. It can also handle channel related security filtering and other restrictions. The control block can have its own register set that can be accessed by privileged software via a separate address range. The DMA control logic block 220 can include an APB interface to the APB bus 222 and can use an interrupt request channel 224 to signal channel and / or global GMAC events. The DMA control logic block 220 can be coupled to the context memory 116 via the context BIU 216, whereby DMA control logic block contexts, such as configuration register values, can be stored and retrieved.

[0051] In one embodiment, the virtual channel context data is stored in a memory external to the DMAC module. The context memory can be a fixed private area in the system memory. If the DMA access of the DMAC and the context memory access do not compete for the same AHB interface, the performance of the DMAC is improved. To this end, the DMAC can have separate AHB interfaces: a data interface 214 dedicated to DMA transfers, and a context interface 216 dedicated to context memory access.

[0052] In addition to other inputs and outputs not shown in Figure 2 The DMAC 102 can also include additional inputs such as a clock (CLK) input and a reset (RESET) input, in addition to other inputs and outputs not shown in

[0053] Configuration data and status information can be stored in software (SW) visible registers of the DMAC. These registers allow software entities with sufficient security and privilege level to configure the behavior and read the status of the DMAC at the DMA unit level, DMA channel level, and DMA command level.

[0054] Configuration data from the command descriptor can be provided from an external source. When command chaining is enabled, the command descriptor is used to configure the DMA command without direct software interaction. The command descriptor can be stored within a linked list data structure in the system memory. Each command has information about which DMA channel configuration registers must be updated and a pointer to the next command.

[0055] Channel context data includes DMAC specific micro-architecture information for each virtual channel. The channel context data is stored externally until a virtual channel is assigned to a physical channel and the context data is loaded into the physical channel registers.

[0056] Hardware (HW) trigger input control information provided via a trigger input port enables a peripheral to start DMA channel operation or implement flow control mechanisms when executing commands. For example, a HW trigger output control information trigger output port can signal another peripheral of the end of a DMA command, implementing a handshake mechanism for synchronization purposes.

[0057] Miscellaneous HW configuration and additional control information can be provided via a top-level port and interface. HW control information can include, for example, boot control signals, default context base addresses, cross-trigger interface (CTI), and secure / non-secure full channel stop and pause handshake interface.

[0058] Figure 3 is a block diagram of a virtual channel 200 of a DMAC according to various representative embodiments. The virtual channel is implemented in hardware. The virtual channel (VCH) implements aspects of DMA transfers unique to each DMA channel, while the physical channel consists of the same logic and resources for each DMA channel. Software executing on the processor is used to configure the channel via values stored in a local virtual channel register set 302. The virtual channel 200 includes a virtual channel control finite state machine (FSM) 304 that tracks and coordinates the lifetime of a DMA command that the channel is executing. For example, during the lifetime of a command, the channel control FSM 304 executes "enable," "disable," "pause," "resume," and "stop" commands, validates command configuration, waits for a trigger input, waits for allocation, handles being in a pre-empted paused state, and performs automatic command restart and command link acquisition.

[0059] Trigger inputs 210 can include DMA source triggers 306, DMA destination triggers 308. Outputs can include output triggers 310 and general purpose outputs 312. A trigger control block 314 provides the interface and related control logic for trigger support. A DMA channel can have a peripheral trigger port for autonomous command and flow control between the DMAC and a peripheral. Each virtual channel has its own trigger control block 314 that handles the corresponding external trigger interface. A virtual channel can generate flow control signals for controlling the flow of a DMA channel. The flow control signals can be based on one or more trigger inputs.

[0060] Trigger input ports enable a peripheral to communicate with the DMAC and order DMAC operations without SW intervention. Triggers provide flow control for transfers within a DMAC operation and can also be used to start a whole DMAC operation. The mode in which triggers are used can be selected via a configurable register.

[0061] In one embodiment, the virtual channel 200 includes a general purpose output (GPO) interface 316. The GPO can be used, for example, to select a memory bank, to indicate channel operation on a debug pin, to control an external hardware entity, etc. The GPOs can be driven per channel, so each virtual channel has its own one or more ports.

[0062] A virtual channel cannot perform DMA transfers without being assigned to a physical channel PCH. Each virtual channel keeps track of its own assignment status via signals from the PCH that are forwarded by the context manager. The context manager controls the virtual channel assignment / de-assignment of physical channels. The virtual channel 200 generates requests 320 to the context manager and receives notifications 322 when assignments are granted.

[0063] The VCH represents the only non-shareable part of a regular DMA channel. Each VCH has its own channel control and stall FSM that tracks and coordinates the lifetime of the DMA commands the channel is executing. Also, the VCH can have its own channel registers implemented locally. Furthermore, the VCH has its own trigger interface and associated control logic when trigger support is configured. Similarly, each VCH has its own GPO interface when GPO support is configured.

[0064] Figure 4 is a block diagram of a physical channel 202 of a DMAC according to various representative embodiments. The physical channel 202 implements read and write control logic 402 for data transfers, including burst computation logic and pipelining. Each physical channel is assigned to one virtual channel at a time. The physical channel also implements command chaining logic 404 to read command descriptors and perform the necessary updates in the local physical channel register set 406 and related registers in the virtual channel and context memory based on the command descriptors. Each physical channel implements its own context fetch / save logic 408 and register reload logic 410 used by commands for which auto-reload is set.

[0065] A command descriptor is a set of values that describe a data transfer. The values are loaded into the physical channel register set 406. For example, the command descriptor can include a source address SRCADDR, a destination address DESADDR, a transfer size TRANSIZE (number of elements to transfer), an element size XSIZE, a source address increment value SRCADDRINC, and a destination address increment value DESADDRINC.

[0066] A DMA command can transfer one or more data values from one or more source addresses in an external source device to one or more destination addresses in an external destination device. The external source device can be, for example, a peripheral device or a memory device. The external destination device can be, for example, a peripheral device or a memory device.

[0067] When a command completes or repeats, the register reload logic 410 updates the command descriptor. If the physical channel is deallocated before the entire transfer is completed, the "pending" command descriptor is saved to context memory. When the virtual channel is next granted access to a physical channel, whether the same physical channel or a different physical channel, the "pending" command is fetched from context memory.

[0068] The physical channel (PCH) 202 includes context control FSM logic 412 that handles interactions with the context manager, including receiving grants 414 and transfer allocation signals 416.

[0069] The physical channel 202 is connected to a bus interface unit (BIU) via a DMA transfer interface 418. The BIU acts as an arbiter between the physical channels operating in parallel and generates transfers on its AHB interface according to requests from the physical channels.

[0070] Table 1 shows example DMA command parameters. These parameters are stored in channel registers and form part of the context information. The channel registers can be stored in the VCH or the PCH. Some channel registers can be split, with some fields of the register stored in the VCH and other fields stored in the PCH. Other sets of parameters can be used without departing from the disclosure.

[0071] Table 1

[0072] In one embodiment, the command chaining feature is used to enable the DMA channel to perform more operations by automatically loading the next command from system memory into its configuration registers. This feature makes the DMAC versatile when combining multiple commands in a DMAC transaction. Each chained command can define new transfer parameters, trigger behavior, and interrupt settings. This provides a great deal of flexibility in the possible use of the DMA unit and makes it possible to implement complex data transfer tasks by carefully designing the command chain. Commands are defined by command descriptors stored in memory. The channel fetches the command descriptor using a pointer address stored in the link register ("LINKADDR" in Table 2 below). The first command is set directly in the channel registers to start the chained command chain. If needed, the first command can be a null command that only points to the memory location with the first non-null command. Some commands can change only some of the configuration registers in the configuration registers, e.g., destination address or number of transfers, but leave all other registers the same for the next command. To this end, the command descriptor in memory has a header section that specifies which registers in the channel register set are updated. This reduces the number of bus transfers performed during command fetch. The command chain ends when a command in the chain does not set a specified bit. For example, the least significant bit of the link address can be used to indicate whether to link additional commands. When a command completes, a new command is fetched. The register values are read and updated according to the header word. For example, the execution of the command chain can be stopped by setting a bit in the channel command register. The currently executing command completes, but the next command is not loaded.

[0073] When a command in the command chain stops, the remainder of the command and the remainder of the command chain are cancelled. The stop waits for all outstanding responses from read and write transactions, but it attempts to complete the channel operation as soon as possible.

[0074] Figure 5 is a block diagram of a context manager 204 of a DMAC according to various representative embodiments. The context manager 204 provides an arbitration layer between virtual channels and physical channels. It determines which virtual channel (VCH) is assigned to which physical channel (PCH), and if needed, which virtual channel is deassigned. By granting or revoking access, the context manager triggers the relevant processes in the involved VCHs and PCHs, which will result in their assignment or deassignment, respectively. Multiplexing of any signaling between VCHs and PCHs is also handled by the context manager. The context manager 204 includes assignment arbitration logic 500 and deassignment arbitration logic 502 that update an assignment table 504 together. Routing control logic 506, e.g., a multiplexer, connects virtual channels to their assigned physical channels.

[0075] The context manager 204 also includes preemptive suspension logic 508. Preemptive suspension prevents priority inversion in DMA, and is discussed in more detail below.

[0076] The context manager 204 receives requests 520 from virtual channels, and responds with grants 522 when a physical channel is allocated to service the request. The context manager 204 provides VCH arbitration grant status 524 to the physical channel, and receives allocation status 526 from the physical channel.

[0077] The context manager 204 can provide allocation arbitration between virtual channels based on the priority of the virtual channels. The highest priority virtual channel wins the arbitration. If two or more virtual channels have the same priority, arbitration between the virtual channels is done based on a least recently granted scheme. With the least recently granted scheme, the earliest selected virtual channel wins the arbitration.

[0078] Figure 6 is a block diagram of the DMA control logic block 220 according to various representative embodiments. The DMA control logic block 220 receives configuration and control commands from one or more processors (via bus APB 602), and can provide an interrupt request signal to the processors on IRQ line 604. The DMA control logic block 220 provides a configuration interface that enables the behavior of the DMAC to be configured by a bind off signal or by the values written into the register set 606 when the DMAC is released from reset.

[0079] Stop / suspend logic 608 provides support for responding to start and suspend commands. For example, a command can be used to stop the operation of all active channels of the DMAC. The stop function can be useful when error scenarios in the processing system, and immediate action must clear the DMAC task. The stop waits for all outstanding responses from read and write transactions, and it tries to complete the channel operation as fast as possible by not transmitting more requests and continuously asserting the trigger. The operation of the DMA channels can be suspended at a point in time by a command from an external hardware unit that suspends all channels immediately. The suspend function can be used to freeze the channels in one state and check the current values of their registers, or to suspend the DMA unit for a period of time to free up bus infrastructure resources. The channels can remain enabled. The transmit and trigger states can be preserved so that no information is lost. When the suspend request is de-asserted, the operation continues.

[0080] The DMA control logic block can provide a cross trigger interface (CTI) 610 that allows suspension and resumption of all channels at once. The CTI is needed in systems where the processor is suspended for debugging purposes and the debugger must save the actual memory contents, so the DMAC can also be suspended to avoid corrupting the current state of the system.

[0081] Boot logic 612 provides automatic booting of the DMAC and can be controlled by, for example, a "boot enable" input.

[0082] In one embodiment, certain registers in the APB register space are protected for higher privilege and secure software modules. These registers configure the overall behavior of the DMAC and are protected within the DMAC.

[0083] Context initialization / clear block 614 implements a "register clear" mechanism that clears all channel registers associated with the execution of a DMA command (such as those listed in Table 1 above), and the CHID (channel identifier) register if present. If the VCH is deallocated when the register clear mechanism is executed on the channel's registers, the DMAC clears the corresponding area in the context memory by generating a write transfer on the context bus.

[0084] Block 616 monitors changes in the security and privilege settings of a virtual channel. Both events trigger a register clear sequence to prevent data leakage.

[0085] Figure 7 is a block diagram of a data bus interface (BIU) 214 of a DMAC according to various representative embodiments. Data BIU 214 includes physical channel arbitration logic 700 for the AHB. This arbitrates between bus access requests from multiple physical channels (e.g., PCH0 and PCH1 in Figure 2 AHB register slice 702 is a pipeline buffer that provides timing isolation of bus signals and implements matching of signal delays and latencies. Transfer generation block 704 generates bus data corresponding to requests received from the physical channels.

[0086] Figure 8 is a block diagram of a context bus interface (BIU) 216 of a DMAC according to various representative embodiments. Context BIU 216 includes physical channel arbitration logic 800 for the AHB that arbitrates between bus access requests from multiple physical channels (e.g., PCH0 and PCH1 in Figure 2 AHB register slice 802 provides timing isolation of bus signals to implement matching of delays and latencies. Transfer generation block 804 generates bus data corresponding to requests received from the physical channels.

[0087] Figure 9is another block diagram of a physical channel 202 of a DMAC according to various representative embodiments. The physical channel 202 implements read and write control logic 402 for data transfer, including burst computation logic and pipelining. The read and write control logic 402 can include read and write finite state machines (FSMs). Each physical channel is assigned to one virtual channel at a time. The physical channel also implements command chaining logic 404, which can be a finite state machine (FSM), for reading command descriptors and performing the necessary updates in the associated registers in the local physical channel register set 406 and in the virtual channel and context memory based on the command descriptors. Each physical channel implements its own context fetch / save logic 408 and register reload logic 410, which is used by commands for which auto-reload is set. The logic can include finite state machines, as described below.

[0088] A command descriptor is a set of values that describe a data transfer. For example, the values are loaded from system memory into the physical channel register set 406. In one embodiment, the command descriptor includes a source address SRCADDR, a destination address DESADDR, a transfer size TRANSIZE (the number of elements to transfer), an element size XSIZE, a source address increment value SRCADDRINC, and a destination address increment value DESADDRINC.

[0089] The registers can be wide registers (e.g., 32 bits). Since there are fewer physical channels than virtual channels, placing the registers in the physical channels reduces the footprint of the DMAC circuit.

[0090] When the read / write of an element is complete, the update logic 902 updates the command descriptor. In one embodiment, the command descriptor is updated.

[0091] SRCADDR SRCADDR + SRCADDRINC * XSIZE DESADDR DESADDR + DESADDRINC * XSIZE TRANSIZE TRANSIZE - 1 The values of XSIZE, SRCADDRINC, and DESADDRINC are unchanged. The updated command descriptor indicates the still outstanding portion of the total transfer. If the physical channel is deallocated before the entire transfer is complete, the "outstanding" command descriptor is saved to the context memory. When the virtual channel is next granted access to a physical channel, whether it is the same physical channel or a different physical channel, the "outstanding" command is fetched from the context memory.

[0092] The physical channel (PCH) 202 includes context control FSM logic 412 that handles interactions with the context manager, including receiving grants 414 and transmitting allocation signals 416.

[0093] Figure 10 is a graphical schematic of a read and write finite state machine (FSM) according to various representative embodiments. The module generates data read and write bursts to be requested from the BIU. The FSM waits in an initial "idle" state 1002 until the virtual channel control FSM (VCH CTRL FSM) reaches a data transfer state, at which point it transitions to the INIT state 1004. In the INIT state, internal registers are loaded to compute the work length and burst size. The FSM changes to the "read" state 1006 with the next clock. In the "read" state 1005, read bursts are generated as long as there is available space in the FIFO of the BIU, or until a "stop," "pause," or "transfer release" request is received. When the read is complete (the FIFO is full), the FSM transitions to the "write" state 1008, in which write bursts are generated as long as there is data in the FIFO of the BIU or a "stop" request is received. When the write is complete, if the remaining work length (WRKLEN) is zero, or a "pause" or "release" request is received, the FSM transitions to the "idle" state 1002, as depicted by the positive branch of decision block 1010. Otherwise, when WRKLEN > 0, the FSM returns to the "read" state 1006.

[0094] While in the "read" or "write" states, a "stop" request can be received. If the current transfer is the last transfer, as indicated by the positive branch of decision block 1012, the FSM transitions to the "idle" state 1002. Otherwise, as depicted by the negative branch of decision block 1012, the FSM transitions to the EMPTY LAST TRANS state 1014, in which the last transfer is emptied. The FSM then transitions to the "idle" state 1002.

[0095] Figure 11 is a block diagram of a context manager according to various representative embodiments. Figure 11Allocation and deallocation logic is shown. The function of the context manager is to control the allocation and deallocation process, to track the current allocation status of virtual and physical channels, to intervene if there is a priority inversion scenario, and to create connections between virtual and physical channels allocated to each other. When virtual channels reach a point in their operation where they need the functionality of a physical channel to progress, they request allocation by providing an "allocation request" signal to the VCH allocation arbiter 1102. The context manager is responsible for arbitrating between multiple allocation requests from virtual channels. Allocation arbitration between virtual channels is done based on their priority. The priority value of each virtual channel is indicated by the "priority" signal provided to the VCH allocation arbiter 1102.

[0096] Signal 1104 indicates the currently selected virtual channel for allocation and is fed to multiplexer 1106.

[0097] Signal 1108 generated by the PCH allocation selector 1110 indicates the allocated physical channel. This signal is computed using the "PCH allocated" and "PCH allocation in progress" signals, which are combined in a logical OR unit 1112. Signal 1108 controls multiplexer 1106 and determines which entry of allocation table 1114 will store the identifier of the selected VCH. Each entry of allocation table 1114 is associated with a physical channel and stores the identifier of the virtual channel to which the physical channel is allocated.

[0098] "Allocation enable" signal 1116 can be asserted when there is at least one virtual channel requesting allocation and there is a physical channel that is either deallocated or the requesting virtual channel currently selected by the allocation arbiter still holds its physical channel context. PCH selection signal 1108 controls multiplexer 1118 to deliver "PCH allocation start" signal 1120 to the selected physical channel. Multiplexer 1118 is part of the routing control logic.

[0099] When a virtual channel reaches a point in its operation where it no longer needs the functionality of a physical channel, even temporarily, it uses the "hint" signal to hint deallocation to the VCH deallocation arbiter 1130. A virtual channel can hint that it can be deallocated from a physical channel when it is in one of the following states: • disabled state • command triggered state if the trigger request is "low" • flow control triggered state if the trigger request is "low" • triggered output state if the trigger acknowledge is "low" • paused or preempted paused state The context manager is responsible for arbitrating between multiple deallocation hints from the virtual channels. Deallocation hints can only come from "allocated" virtual channels. The VCH deallocation arbiter 1130 selects the VCH indicated in signal 1132 for allocation based on the hint and also based on the state of the VCH (indicated by signal "state") and the priority of the VCH (indicated by priority signal "priority").

[0100] The PCH deallocation selector 1134 selects the physical channel to deallocate based on the selected VCH 1132 and the contents of the allocation table 1114. The selected physical channel is used to control multiplexer 1136 to route deallocation enable signal 1138 to the selected physical channel as PCH deallocation start signal 1140. The deallocation enable signal 1138 indicates a deallocation arbitration point when there is at least one virtual channel requesting allocation, there is at least one virtual channel that can be deallocated (i.e., hint deallocation), and all physical channels are "allocated."

[0101] Thus, the context manager receives allocation requests and deallocation hints from the VCHs and generates allocation and deallocation start signals for the PCHs.

[0102] Figure 12 is a further block diagram of a context manager according to various representative embodiments. As described above with reference to Figure 11 Each entry in the allocation table 1114 is associated with a physical channel and contains the identifiers of the virtual channels allocated to that physical channel. The entries are used to control downstream signal multiplexer 1202 and upstream signal multiplexer 1204 to route signals between the virtual channels and the allocated physical channels. Multiplexers 1202 and 1204 are part of the routing control logic of the context manager. The signals can include, for example, status signals. For each of the n+1 physical channels (PCH0-PCHn), there is one upstream multiplexer and one downstream multiplexer, and each multiplexer switches between m+1 virtual channels (VCH0-VCHm).

[0103] Figure 13 is a graphical illustration of a context FSM for a physical channel according to various representative embodiments. At startup, the physical channel is in the "deallocated" state 1302. A rising edge on the "allocation start" signal (1120 in Figure 11 indicates the start of the allocation process. This causes the FSM to transition to the "CTX get" state 1304, which indicates context get. When the context get is complete, the FSM transitions to the "allocated" state 1306.

[0104] "deallocation start" signal (1138 inFigure 11 the rising edge on the "CTX save" signal (at 1140 in FIG. 11) indicates that the associated VCH is being deallocated, and the internal PCH register value must be saved to CTX MEM. This causes the FSM to transition to the "CTX save" state 1308. When the context save is complete, the FSM transitions back to the "deallocated" state 1302.

[0105] If a bus error occurs while acquiring or saving a context, the FSM transitions back to the "deallocated" state 1302.

[0106] Figure 14 is a block diagram showing the flow of signals according to various representative embodiments. The signals flow between the virtual channels 200 and the physical channels 202 via the context manager 204. The context manager 204 provides an arbitration layer between the virtual channels 200 and the physical channels 202. It describes which virtual channel is assigned to which physical channel, and if necessary, determines which virtual channel is deallocated. By granting or revoking access, the context manager triggers the relevant procedures in the VCHs and PCHs involved, which will result in their assignment or deallocation, respectively. Multiplexing of any signaling between the VCHs and PCHs is also handled by the context manager.

[0107] The virtual channels utilize the signal "VCH assignment request" to request assignment in the context manager. When the assignment arbiter 500 selects a virtual channel for assignment and the conditions for the assignment arbitration point are met, the context manager arbitrates between these requests, and the virtual channel is granted as signaled by the signal "VCH assignment granted". When the assignment grant indicated in the signal "multiplexed VCH grant status" is issued by the context manager, the physical channel 202 is connected to the virtual channel 200. The downstream multiplexer of the multiplexer 506 selects the assigned PCH. At this point, the physical channel starts context acquisition, and when it finishes processing, it signals the virtual channel that it has been assigned. From that point, both the physical channel and the virtual channel are in the assigned state.

[0108] The allocation sequence starts with an allocation grant for any one of the request virtual channels requesting a virtual channel. It contains the complete procedure for context acquisition controlled by the virtual channel and the physical channel and continues until the physical channel signals that it has been allocated. The virtual channel uses the signal "VCH deallocation hint" to hint to the deallocation arbiter 502 of the context manager that a deallocation is possible. When the deallocation arbitration selects a virtual channel for deallocation and the conditions of the deallocation arbitration point are met, the context manager arbitrates between these hints and the virtual channel is revoked as indicated by the signal "VCH allocation revocation". When the connected virtual channel is revoked, the corresponding physical channel starts the context save. When this procedure is finished, it signals to the virtual channel that it has been deallocated using the "PCH allocation status" signal. The deallocation sequence starts with an allocation revocation for any of the virtual channels in the virtual channel that is signaling a deallocation hint. It contains the complete procedure for context save controlled by the virtual channel and the physical channel and continues until the physical channel signals that it has been deallocated. The physical channel has a context FSM that controls the context switch procedure.

[0109] The preemptive pause logic 508 prevents priority inversion in the DMA, which is when a high priority virtual channel cannot access the physical channel because a lower priority virtual channel cannot proceed with its operation. Since it cannot proceed, it never gets to the point where it can relinquish its shared resources to the high priority virtual channel. When the context manager detects an incoming allocation request from a high priority channel that cannot be granted due to the above reasons, a preemptive pause request is issued by the context manager in the signal "VCH preemptive pause request". The preemptive pause request is issued to the lowest priority allocated virtual channel, which forwards the request to the physical channel allocated to it. The VCH can use the "VCH pause request hint" signal to hint to the context manager that a pause is possible. When a VCH pause is selected, the allocated PCH is signaled in the signal "Multiplexed VCH pause request". See below for a description of the priority inversion example. Figure 20 The "PCH activity indication" signal is passed to the context manager and routed to the paired VCH in the signal "Multiplexed PCH activity indication".

[0110] The "VCH DMA command signaling" signal is passed to the context manager and routed to the allocated PCH in the signal "Multiplexed DMA command signaling".

[0111] Additional signaling can be incorporated without departing from the disclosure.

[0112] Figure 15A and Figure 15Btogether constitute a flowchart of a virtual channel control FSM according to various representative embodiments. Reference is made to Figure 15A Referring to the flowchart 1500 in Figure 15A , the VCH control FSM begins in a default "disabled" state 1505 in which the channel is inactive and no command execution occurs. If the "auto-start" feature is enabled, as depicted by the affirmative branch of decision block 1506, the VCH transitions to the DP_CMDLINK state to begin acquiring a boot command and then to CMDLINK. If the command trigger and first flow control trigger request are enabled, as depicted by the affirmative branch of decision block 1508, the channel transitions to the CMDTRIG state 1510 when it is enabled. In the CMD TRIG state 1510, the FSM waits for the command trigger request and the first flow control trigger request. Once the enablement occurs, the general purpose outputs (GPOs) can be set based on the GPO configuration.

[0113] If the trigger is not enabled or has arrived and the VCH is not "allocated" (i.e., not running), as depicted by the negative branch of decision block 1512, the FSM transitions to the "transfer start" state 1515 to wait for allocation. Once "allocated," it transitions to the next state.

[0114] The initial values of the reloadable registers (source and destination addresses and size registers) must be saved to context memory unless register reload is disabled in the configuration. As depicted by the affirmative branch of decision block 1518, the VCH control FSM transitions to the "save reload" state 1520 and the physical channel begins the save process. The next state is the "transfer" state 1525 in which the data read and write are performed to transfer data from the source to the destination. Once the VCH control FSM is in the "transfer" state, the transfer is generated by the allocated physical channel. If a PCH error occurs while in the transfer state 1525, the FSM transitions to the "stop" state 1535.

[0115] If the flow control trigger is enabled, the virtual channel will wait for the trigger input request in the FLW TRIG state 1530.

[0116] After all the transfers of the command have been transferred, the flow continues to point "A" in the flowchart 1536 in Figure 15B .

[0117] Referring to Figure 15BIf reload is enabled, as depicted by the positive branch of decision block 1538, the FSM transitions to the CMD RELOAD state 1540. In this state, the initial values of the registers are reloaded from context memory. This is done by the physical channel, which starts the load process as soon as the VCH control FSM is in the "CMD RELOAD" state. If reload is disabled, the reload is skipped. If the output trigger is enabled, as depicted by the positive branch of decision block 1542, the virtual channel will set its output trigger request and will wait for acknowledgement in the "output trigger" state 1545. Once all data is transferred, all trigger handshakes are completed, and the initial values are reloaded, the virtual channel transitions to the "done" state 1550.

[0118] If the DMAC is configured to automatically restart commands, the FSM jumps back to the Figure 15B "DP" is an acronym for "done pause"). The previous command execution can be restarted with the same or updated size and address parameters. The restart counter is decremented if needed while in the "done" state 1550.

[0119] If automatic restart is not enabled for the command, as depicted by the negative branch of decision block 1552, but command chaining is enabled, the FSM transitions to the DP_CMDLINK state 1560 if done pause is enabled and to the CMDLINK state 1560 if done pause is not enabled. This starts the reading of the next command from memory. This is done by the physical channel, which starts the command link read process as soon as the VCH control FSM is in the CMDLINK state. When the reading of the new command is completed, the virtual channel starts the execution of this new command by transitioning to point "B" in the flowchart 1500.

[0120] If the done pause field is set to pause at the end of cycle or at the end of command, both automatic restart and command chaining can be stopped. In this case, the VCH control FSM waits for resumption in the DP_AUTO-RESTART state 1555 and the DP_CMDLINK state 1560.

[0121] If neither automatic restart nor command chaining is enabled, the VCH control FSM returns to the "disabled" state.

[0122] If the virtual channel encounters an error condition from the physical channel or gets a stop request, it transitions to the "stop" state (1535 in flowchart 1500), in which it waits for all interfaces and internal states to return to idle, after which the VCH control FSM returns to the "disabled" state.

[0123] Figure 16 is an example timing diagram for channel operation according to an embodiment. In this example, a "done" interrupt signal is generated when the command completes and "done-pending" is enabled. The timing diagram shows how a chained command is configured and executed by the channel when using the "done" interrupt, where "done-pending" is enabled to pause operation until external software resumes execution. The following steps are described in more detail.

[0124] At time tO, a command descriptor is written into memory and the DMA channel registers are configured. The last step of the configuration process is to set the "enable" bit to start the channel operation.

[0125] At time tl, the channel starts by waiting for a peripheral to trigger a block-based DMA request. When the trigger arrives, the DMA performs the preconfigured number of reads and writes for that trigger event.

[0126] At time t2, the channel waits for another trigger to perform the final read and write operations for the command. When the data is received, the move is performed as described previously.

[0127] At time t3, the channel asserts the trigger output and waits for the acknowledgement to arrive. The channel operation is paused until the acknowledgement is received.

[0128] At time t4, the acknowledgement is received. This is the last step for this command. The configuration enables the "done" interrupt with "done-pending" set for this command. This stops further operation until the command is resumed by external software. This can be used as a synchronization point between DMA and software to ensure that all software activity is completed before the DMA starts executing the next command. When the interrupt is acknowledged, the DMA starts reading the chained command.

[0129] At time t5, the DMAC reads the chained address. Based on the command header, the new values read are applied to the registers. When all necessary registers are read, the next command starts execution.

[0130] At time t6, the next command is just a few reads and writes, and then again the "done" interrupt is raised. The channel remains enabled until any interrupts are pending. When the interrupt is cleared, the operation is complete, regardless of the "done-pending" enable setting, since this is the final command of the chain.

[0131] At time t7, the interrupt is acknowledged, and the channel returns to the "idle" state.

[0132] Figure 17 is an example timing diagram for channel operation according to an embodiment. This example shows command execution when a single command is looped several times and then disabled by software. This example uses a trigger output to provide control over the periodicity of the loop. This enables the command to be looped without any triggers or interrupts. The upper boxes indicate the state of the channel, while the lower boxes indicate the channel operation. These steps are described in more detail: At time to, only the DMA channel registers need to be configured. For example, the "channel auto-configuration" register can be configured before the "enable" bit to start the channel operation in loop mode. The channel is in the "idle" state.

[0133] At time ti, the channel performs several read and write operations and then waits for the trigger output to be acknowledged.

[0134] At time t2, the final write response is received and the trigger is acknowledged. At this point, the channel reloads the start value for the current command from its internal registers.

[0135] At time t3, the register value is set back to start and the command can begin again by performing the same read and write operations.

[0136] At time t4, the trigger acknowledgement is received again at the end of the command and the same values are reloaded again to start the next loop.

[0137] At time t5, the same read and write operations are performed by the command.

[0138] At time t6, the software writes the specified "disable" bit for the command to indicate that the loop should complete at the end of the command. The command still waits for the trigger acknowledgement at the end of the cycle.

[0139] At time t7, the register value is not reloaded at the end, so the channel returns to the "idle" state.

[0140] Figure 18is an example timing diagram according to various representative embodiments. This example illustrates a scenario where two VCHs (VCH0 and VCH1) are deallocated at time to and request allocation shortly thereafter. As indicated by the VCH0 request signal, the deallocated VCH0 requests allocation. Since at least one PCH is free and there are no other ongoing allocation or deallocation sequences, the request is immediately granted by the context manager as indicated by the VCH0 grant signal. Since PCH0 is the lowest indexed free PCH, the context manager selects PCH0 as the allocation pair for VCH0. As indicated by the PCH0 CTX-FSM, the state of PCH0 transitions from "Deallocated" to "CTX Acquire" at time ti and PCH0 begins context acquisition. At the same time, as indicated by the VCH1 request signal going high, the unallocated VCH1 requests allocation. Since the allocation sequence for the VCH0-PCH0 pair is not complete, the context manager does not immediately grant the allocation even though PCH1 is free, as this would result in starting a second allocation sequence. PCH0 completes context acquisition at time t2 and is fully allocated. At the same time, VCH1 receives a grant from the context manager as indicated by the signal VCH1 grant and will be allocated to PCH1. Thus, at time t3, the PCH1 context FSM transitions from the "Deallocated" state to the "CTX Acquire" state and PCH1 begins context acquisition. PCH1 completes context acquisition at time t4 and is fully allocated. In this example, there is a delay from the VCH1 request for allocation to the allocation being granted.

[0141] Figure 19 is an example timing diagram according to various representative embodiments. This example illustrates a simple context switch scenario.

[0142] At time to, VCH0 is allocated to PCH0 as indicated by the VCH0 CTX-FSM state in the figure. VCH0 does not actively perform a transfer, but rather asserts its deallocation hint to the context manager indicating that it can be revoked if needed. This is indicated by the VCH0 DEALLOC_HINT signal in the figure. VCH1, which has the same or higher priority than VCH0, requests allocation. It immediately wins arbitration and thus the context manager revokes VCH0 at time ti.

[0143] At time ti, VCH0 is revoked and PCH0 begins context save as indicated by the PCH0 CTX-FSM transitioning to the "CTX Save" state in the figure.

[0144] At time t2, PCH0 completes context save and is deallocated, thus the CTXMGR signal grants to VCH1 as indicated by the VCH1 grant signal.

[0145] At time t3, VCH0 is deallocated, as indicated by the VCH0 CTX-FSM transitioning to the "Deallocated" state. In addition, at time t3, VCH1 is granted, and PCH0 begins VCH1 context acquisition.

[0146] At time t4, PCH0 completes context acquisition and is allocated.

[0147] At time t5, VCH1 captures the PCH0 allocation state and itself is allocated.

[0148] Figure 20 is a timing diagram of a DMAC in accordance with various representative embodiments. In Figure 20In the example shown, there are three channels: channel A with low priority, and channels B and C with high priority. At time to, all channels are de-allocated. Channel A, associated with VCH-A, first requests allocation, as indicated by the "VCH-A request" signal. PCH-0 is selected for allocation to VCH-A, and the associated context switch is performed. At time ti, DMA channel A begins accessing the data bus. For example, channel A can generate a burst of data. Channel B, associated with VCH-B, next requests allocation, and PCH-1 is allocated to VCH-B. Channel B's transmission has higher priority, and is selected by the arbitrator of the data BIU. Since channel C has the highest priority, external software expects it to take over channels A and B within a reasonable amount of time when channel C is enabled. Channel A, with the lowest priority, should context switch with channel C, but cannot context switch until the pending transmission of channel A is complete. However, since channel B has higher priority, the BIU is arbitrating channel B's transmission, and so the transmission cannot complete. Thus, channel A blocks channel C, and channel C cannot proceed because it is not allocated and cannot generate any transmissions. This situation is resolved by the context manager sending a pre-emptive pause request to VCH-A, with the lowest priority, at time ti. At this point, all PCHs are allocated, and the context manager has received allocation requests from higher priority channels. At time t2, the first channel A transmission completes, and VCH-A acknowledges the pause request, indicating that its allocation can be revoked. At time t3, the VCH-A context FSM enters the "revoked" state. PCH-0 is re-allocated to VCH-C, and the associated context switch begins. At time t4, the re-allocation is complete. The BIU determines that channel C has the highest priority, and begins channel C transmission on the data bus. At time t5, channel B transmission completes, and PCH-1 is re-allocated from VCH-B to VCH-A. When channel C transmission completes, at time t6, channel A transmission can finally proceed on the data bus. In this way, the highest priority channel has been able to complete its operation by displacing the lowest priority channel.

[0149] In summary, embodiments of the present disclosure provide a direct memory access controller (DMAC) that includes virtual channels, physical channels, and a context manager. The virtual channels are configured to generate flow control signals for executing direct memory access (DMA) commands. The physical channels include read and write control logic for initiating data transfers from a source device to a destination device according to the DMA commands in response to the flow control signals. The context manager includes allocation logic configured to arbitrate between allocation requests from the virtual channels and allocate a physical channel to a selected virtual channel, and routing logic configured to route the flow control signals from the selected virtual channel to the allocated physical channel.

[0150] The virtual channels can include one or more channel control registers programmable by an external device to provide a trigger input, where the virtual channels are configured to generate the flow control signals in response to the trigger input.

[0151] The virtual channels can also include one or more trigger ports configured to be coupled to an external source device or an external destination device, and a control finite state machine (FSM) configured to control direct memory access (DMA) commands in the virtual channel in response to signals on the one or more trigger ports. The control FSM can also generate the flow control signals based at least in part on a signal from a trigger port of the one or more trigger ports.

[0152] The context manager can also include deallocation logic, in which case the control FSM of a virtual channel is configured to signal the context manager when the virtual channel is in a state in which it can be deallocated by the context manager. The context manager can also issue a pre-emptive pause request to a lowest priority virtual channel when a higher priority virtual channel cannot access a physical channel because a lower priority virtual channel cannot perform its operations. The lowest priority virtual channel forwards the pre-emptive pause request to the physical channel allocated to it.

[0153] In one embodiment, the physical channels include a command descriptor storage area configured to store command parameters, corresponding command descriptor update logic configured to update one or more of the command parameters stored in the command descriptor storage area, and a context fetch and save finite state machine (FSM) for transferring the command parameters between the command descriptor storage area and a context memory. The command parameters can include, for example, a source address and a destination address, a source address increment and a destination address increment, a data block size, and a number of outstanding transfers.

[0154] In one embodiment, the DMAC includes a DMA control logic block configured to clear all channel registers related to execution of DMA commands when a virtual channel is deallocated, and generate a write command to clear the associated region in context memory. The context memory can be coupled to the DMAC via a bus, where the DMAC further includes a context bus interface unit coupled to one or more physical channels. The context bus interface unit can include bus arbitration logic to arbitrate between bus access requests from multiple physical channels, and transfer generation logic to generate bus requests corresponding to requests received from physical channels.

[0155] In one embodiment, the DMAC includes a DMA control logic block with DMAC global control logic, a bus interface to exchange configuration data with external hardware, an interface to virtual channel configuration registers and physical channel configuration registers, and a bridge to a context bus interface unit to enable external hardware to access context memory. The DMA control logic block can further include an interrupt controller configured to collect DMA channel status signals from virtual channels, and generate interrupt signals on associated channels on an interrupt bus from the DMA channel status signals.

[0156] In one embodiment, the external source device and the external destination device are coupled to the DMAC via a data bus, and the DMAC includes a data bus interface unit (BIU) coupled to one or more physical channels. The BIU includes bus arbitration logic to arbitrate between bus access requests from multiple physical channels, transfer generation logic to generate bus requests corresponding to requests received from physical channels, and a buffer to store data read from the external source device and to be written to the external destination device.

[0157] In one embodiment, the routing logic of the context manager includes an allocation table maintained by the arbitration logic, each entry in the allocation table corresponding to a physical channel and indicating a virtual channel to which the physical channel is allocated. For each physical channel, a virtual-to-physical multiplexer selects a virtual channel according to the entry in the allocation table for the physical channel, and routes signals from the selected virtual channel to the physical channel. For each physical channel, a physical-to-virtual multiplexer selects a virtual channel according to the entry in the allocation table for the physical channel, and routes signals from the physical channel to the selected virtual channel.

[0158] As described above, computer readable code for manufacturing a direct memory access controller (DMAC) can be stored on a non-transitory computer readable medium.

[0159] In one embodiment, a method of data transfer in a data processing system includes configuring a command descriptor of a direct memory access (DMA) controller (DMAC) for a DMA channel between an external source device and an external destination device by external hardware. The DMAC includes circuitry for virtual channels, physical channels, and a context manager. In response to an allocation request from one or more virtual channels, the context manager allocates a physical channel to a selected virtual channel, and the selected virtual channel generates a flow control signal. The flow signal can be generated in response to one or more trigger inputs from the external source device, the external destination device, or both. In response to the flow control signal, the allocated physical channel initiates transfer of data from one or more source addresses in the external source device to one or more destination addresses in the external destination device according to the command descriptor. The context manager routes the flow control signal from the selected virtual channel to the allocated physical channel.

[0160] The command descriptor can include command parameters such as source and destination addresses, source and destination address increments, data block size, and number of data blocks to be transferred between the external source device and the external destination device.

[0161] The DMAC can be configured to clear a channel register when a specified bit in a header of the command descriptor is set.

[0162] In one embodiment, allocating a physical channel to a virtual channel includes selecting a virtual channel of a plurality of virtual channels requesting allocation based at least in part on a priority value of the virtual channel, selecting a physical channel of one or more physical channels that is neither allocated nor in the process of being allocated, and storing an identifier of the selected virtual channel in an entry of an allocation table corresponding to the selected physical channel.

[0163] The routing by the context manager can include controlling a multiplexer of the DMAC according to the entries of the allocation table.

[0164] In response to a change in allocation of the physical channel, an embodiment of the method includes saving a current context of the physical channel to a context memory, and fetching a new context of the physical channel from the context memory. The saving or fetching of the context can include accessing the external context memory via a bus.

[0165] In one embodiment, the method includes, in response to completion of data transfer from the source external device to the destination external device according to a first command descriptor, reloading the first command descriptor, fetching a second command descriptor from the context memory, or deallocating the physical channel.

[0166] Embodiments of the present disclosure also include the following numbered items, which can be combined: Item 1. A direct memory access controller (DMAC) comprising: a plurality of virtual channels, a virtual channel of the plurality of virtual channels configured to generate a flow control signal for execution of a direct memory access (DMA) command; one or more physical channels, a physical channel of the one or more physical channels comprising read and write control logic for initiating data transfers from one or more source addresses in an external source device to one or more destination addresses in an external destination device according to the DMA command in response to the flow control signal; and a context manager. The context manager comprises: allocation logic configured to arbitrate between allocation requests from the plurality of virtual channels and allocate a physical channel of the one or more physical channels to a selected virtual channel of the plurality of virtual channels; and routing logic configured to route the flow control signal from the selected virtual channel to the allocated physical channel and route status signals from the allocated physical channel to the selected virtual channel.

[0167] Item 2. The direct memory access controller (DMAC) of item 1, wherein a virtual channel of the plurality of virtual channels comprises one or more channel control registers that are programmable by an external device to provide a trigger input, wherein the virtual channel is configured to generate the flow control signal in response to the trigger input.

[0168] Item 3. The direct memory access controller (DMAC) of item 1, wherein a virtual channel of the plurality of virtual channels comprises: one or more trigger ports configured to be coupled to the external source device or the external destination device; and a control finite state machine (FSM) configured to control a direct memory access (DMA) command in the virtual channel in response to signals on the one or more trigger ports.

[0169] Item 4. The direct memory access controller (DMAC) of item 3, wherein the control FSM of the virtual channel is further configured to generate the flow control signal based at least in part on a signal from a trigger port of the one or more trigger ports.

[0170] Item 5. The direct memory access controller (DMAC) of item 3, wherein the context manager comprises deallocation logic, and wherein the control FSM of the virtual channel is configured to signal the context manager when the virtual channel is in a state in which it can be deallocated by the context manager.

[0171] Item 6. The direct memory access controller (DMAC) of item 1, wherein the context manager is configured to issue a pre-emptive suspension request to a lowest priority virtual channel when a higher priority virtual channel is unable to access a physical channel due to a lower priority virtual channel being unable to perform its operations, and the lowest priority virtual channel is configured to forward the pre-emptive suspension request to a physical channel assigned to it.

[0172] Item 7. The direct memory access controller (DMAC) of item 1, wherein a physical channel of the one or more physical channels includes a command descriptor storage area configured to store command parameters, a command descriptor update logic configured to update one or more of the command parameters stored in the command descriptor storage area, and a context fetch and save finite state machine (FSM) configured to transfer command parameters between the command descriptor storage area and a context memory.

[0173] Item 8. The direct memory access controller (DMAC) of item 7, wherein the command parameters include source and destination addresses, source and destination address increments, data block size, and number of outstanding transfers.

[0174] Item 9. The direct memory access controller (DMAC) of item 7, further comprising a DMA control logic block configured to clear all channel registers related to the execution of a DMA command when a virtual channel is deallocated, and generate a write command to clear an associated region in the context memory.

[0175] Item 10. The direct memory access controller (DMAC) of item 7, wherein the context memory is coupled to the DMAC via a bus, the DMAC further comprising a context bus interface unit coupled to the one or more physical channels. The context bus interface unit includes bus arbitration logic configured to arbitrate between bus access requests from multiple physical channels, and a transfer generation logic configured to generate bus requests corresponding to requests received from physical channels.

[0176] Item 11. The direct memory access controller (DMAC) of item 1, further comprising a DMA control logic block having DMAC global control logic, a bus interface configured to exchange configuration data with external hardware, an interface to virtual channel and physical channel configuration registers, and a bridge to the context bus interface unit that enables access to the context memory by the external hardware.

[0177] Item 12. The direct memory access controller (DMAC) of item 11, wherein the DMA control logic block further comprises an interrupt controller configured to collect DMA channel status signals from the virtual channels and generate interrupt signals on associated channels on an interrupt bus in accordance with the DMA channel status signals.

[0178] Item 13. The direct memory access controller (DMAC) of item 1, wherein the external source device and the external destination device are coupled to the DMAC via a data bus, the DMAC further comprising a data bus interface unit coupled to the one or more physical channels. The data bus interface unit comprises bus arbitration logic configured to arbitrate between bus access requests from the multiple physical channels, transmission generation logic configured to generate bus requests corresponding to requests received from physical channels, and a buffer configured to store data read from the external source device and to be written to the external destination device.

[0179] Item 14. The direct memory access controller (DMAC) of item 1, wherein the routing logic of the context manager comprises an assignment table maintained by the arbitration logic, each entry in the assignment table corresponding to a physical channel and indicating a virtual channel to which the physical channel is assigned. For each physical channel of the one or more physical channels, a virtual-to-physical multiplexer is configured to select a virtual channel of the multiple virtual channels in accordance with the entry for the physical channel in the assignment table, and to route signals from the selected virtual channel to the physical channel. For each physical channel of the one or more physical channels, a physical-to-virtual multiplexer is configured to select a virtual channel of the multiple virtual channels in accordance with the entry for the physical channel in the assignment table, and to route signals from the physical channel to the selected virtual channel.

[0180] Item 15. A method of data transfer in a data processing system, comprising: allocating, by a context manager of a DMAC, a physical channel of one or more physical channels of the DMAC to a selected virtual channel of a plurality of virtual channels of the DMAC in response to an allocation request from one or more of the plurality of virtual channels; generating, by the selected virtual channel, a flow control signal; initiating, by the physical channel of the one or more physical channels of the DMAC, data transfer from one or more source addresses in an external source device to one or more destination addresses in an external destination device in accordance with a command descriptor for a DMA channel in response to the flow control signal; routing, by the context manager, the flow control signal from the selected virtual channel to the allocated physical channel; and routing, by the context manager, a status signal from the allocated physical channel to the selected virtual channel.

[0181] Item 16. The method of item 15, further comprising configuring the command descriptor of the DMA channel by external hardware.

[0182] Item 17. The method of item 15, wherein the command descriptor includes, as command parameters, a source address and a destination address, a source address increment and a destination address increment, a data block size, and a number of data blocks to be transferred between the external source device and the external destination device.

[0183] Item 18. The method of item 15, wherein generating, by the selected virtual channel, the flow control signal is in response to one or more trigger inputs from the external source device, the external destination device, or both the external source device and the external destination device.

[0184] Item 19. The method of item 15, further comprising clearing a channel register when a designated bit in a header of the command descriptor is set.

[0185] Item 20. The method of item 15, wherein the allocating includes: selecting a virtual channel of the plurality of virtual channels to request allocation based at least in part on a priority value of the virtual channel; selecting a physical channel of the one or more physical channels that is neither allocated nor in the process of being allocated; and storing an identifier of the selected virtual channel in an entry of an allocation table corresponding to the selected physical channel.

[0186] Item 21. The method of item 20, wherein the routing includes controlling a multiplexer of the DMAC in accordance with the entry of the allocation table.

[0187] Item 22. The method of item 15, further comprising, in response to a change in allocation of a physical channel: saving a current context of the physical channel to a context store and retrieving a new context of the physical channel from the context store.

[0188] Item 23. The method of item 22, wherein saving or retrieving a context comprises accessing an external context store via a bus.

[0189] Item 24. The method of item 15, further comprising, in response to completion of a data transfer from the source external device to the destination external device according to a first command descriptor: reloading the first command descriptor, loading a second command descriptor, or deallocating the physical channel.

[0190] Item 25. A non-transitory computer readable medium storing computer readable code for fabricating a direct memory access controller (DMAC) comprising: a plurality of virtual channels, a virtual channel of the plurality of virtual channels configured to generate a flow control signal for executing a direct memory access (DMA) command; one or more physical channels, a physical channel of the one or more physical channels comprising read and write control logic for initiating a data transfer from a source address in an external source device to a destination address in an external destination device according to the DMA command in response to the flow control signal; and a context manager. The context manager comprising: allocation logic configured to arbitrate between allocation requests from the plurality of virtual channels and allocate a physical channel of the one or more physical channels to a selected virtual channel of the plurality of virtual channels; and routing logic configured to route a flow control signal from the selected virtual channel to the allocated physical channel and route a status signal from the allocated physical channel to the selected virtual channel.

[0191] In this document, relational terms such as first and second, top and bottom, and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," "includes," "including," "contains," "containing," "has," "having," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, includes, contains, has, or the like a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by "comprises a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises, includes, or the like the element.

[0192] References throughout this document to “one embodiment,” “certain embodiments,” “an embodiment,” “the implementation,” “aspects,” or similar terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of such phrases in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures, or characteristics can be combined in any suitable manner in one or more embodiments without limitation.

[0193] As used herein, the term “or” is to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” means “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” Only when appearances of the term “or” are explicitly stated in some other manner are there exceptions to this definition.

[0194] As used herein, the term “configured to” means that the element can be designed or constructed to perform the specified function, or has the necessary structure to reconfigure or adapt to perform the function.

[0195] Numerous details are set forth to provide an understanding of the embodiments described herein. The embodiments can be practiced without these details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. The disclosure should not be construed as limited to the embodiments described herein.

[0196] Those skilled in the art will recognize that the disclosure has been made by way of example. The disclosure can be implemented using hardware components, such as application specific integrated circuits, or processors programmed with specific logic. Similarly, a specific processor and / or hardwired logic can be used to construct an alternative equivalent implementation of the disclosure.

[0197] Specialized or reconfigurable hardware components for implementing the disclosed mechanisms can be described, for example, by instructions in a hardware description language (HDL), such as VHDL, Verilog, or RTL (register transfer language), or by a netlist of components and connections. The instructions can be at the functional level or the logic level, or a combination. The instructions or netlist can be input to an automated design or manufacturing process, sometimes called high-level synthesis, which interprets the instructions and creates digital hardware that implements the described functionality or logic.

[0198] The HDL instructions or netlist can be stored on a non-transitory computer readable medium, such as an electrically erasable programmable read only memory (EEPROM); a non-volatile memory (NVM); a mass storage device, such as a hard disk drive, floppy disk drive, optical disk drive; an optical storage element, a magnetic storage element, a magneto-optical storage element, a flash memory, a magnetic core memory, and / or other equivalent storage technology without departing from the present disclosure. Such alternative storage devices should be considered equivalents.

[0199] The concepts described herein can be embodied in computer readable code for manufacturing devices embodying the described concepts. For example, the computer readable code can be used in one or more stages of a semiconductor design and fabrication process, including electronic design automation (EDA) stages, to manufacture integrated circuits that include devices embodying these concepts. The computer readable code described above can additionally or alternatively enable definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

[0200] For example, the computer readable code for manufacturing devices embodying the concepts described herein can be embodied in code that defines a hardware description language (HDL) representation of the concepts. For example, the code can define a register transfer level (RTL) abstraction of one or more logic circuits for defining devices embodying the concepts. The code can define an HDL representation of one or more logic circuits of a device in Verilog, SystemVerilog, Chisel, or VHDL (very high speed integrated circuit hardware description language), as well as intermediate representations such as FIRRTL. The computer readable code can provide definitions embodying the concepts using a system level modeling language such as SystemC and SystemVerilog, or other behavioral representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts.

[0201] Additionally or alternatively, the computer readable code can define a low level description of integrated circuit components embodying the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more netlists or other computer readable representations of integrated circuit components can be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for manufacturing devices embodying the invention. Alternatively or additionally, one or more logic synthesis processes can generate a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA can be deployed for the purpose of verifying and testing the concepts prior to manufacturing integrated circuits, or the FPGA can be deployed directly in a product.

[0202] The computer readable code can comprise a mix of code representations for manufacturing the apparatus, for example comprising one or more of an RTL representation, a netlist representation or another computer readable definition used in the semiconductor design and fabrication process for manufacturing an apparatus embodying the invention. Alternatively or additionally, the concept can be defined in a combination of a computer readable definition of the apparatus for manufacturing and computer readable code defining instructions to be executed by the defined apparatus once manufactured, in the semiconductor design and fabrication process.

[0203] Such computer readable code can be provided on any of the known transient computer readable media such as a wired or wireless transmission of the code over a network, or non-transient computer readable media such as a semiconductor, disk, or optical disk. An integrated circuit manufactured using the computer readable code can comprise components such as one or more of a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or other components embodying the concept individually or collectively.

[0204] The various embodiments described herein are implemented using specialized hardware, configurable hardware, or programmed processors executing programmed instructions for performing; the programmed instructions are broadly described in flow chart form in the figures, which can be stored on any suitable electronic storage medium or transmitted over any suitable electronic communication medium. Combinations of the above can be used. Those skilled in the art will appreciate that the processes and mechanisms described above can be implemented in many different matching variations and embodiments other than those described without departing from the scope of the disclosure. For example, the order of some operations can be changed, additional operations can be added or removed, and some operations can be performed concurrently, without departing from the scope of the present disclosure. Such variations are contemplated and considered equivalent.

[0205] The various representative embodiments which have been described in detail in the specifi cation hereinabove are presented by way of example and not limitation. It will be apparent to persons skilled in the art that various changes can be made without departing from the scope of the claims which follow. It is therefore intended that the scope of the invention be determined solely by reference to that claims.

Claims

1. A direct memory access controller (DMAC), comprising: Multiple virtual channels, one of which is configured to generate flow control signals for executing direct memory access (DMA) commands; One or more physical channels, wherein one of the physical channels includes read and write control logic, the read and write control logic being used to initiate data transmission from one or more source addresses in an external source device to one or more destination addresses in an external destination device in response to the flow control signal according to the DMA command; and Context manager, the context manager including: Allocation logic, configured to arbitrate allocation requests from the plurality of virtual channels, and to allocate a physical channel from the one or more physical channels to a selected virtual channel from the plurality of virtual channels; and The routing logic is configured to route flow control signals from the selected virtual channel to the assigned physical channel, and to route status signals from the assigned physical channel to the selected virtual channel.

2. The Direct Memory Access Controller (DMAC) of claim 1, wherein the virtual channels among the plurality of virtual channels include: One or more channel control registers that can be programmed by an external device to provide trigger inputs. The virtual channel is configured to generate the flow control signal in response to the trigger input.

3. The Direct Memory Access Controller (DMAC) of claim 1, wherein the virtual channels among the plurality of virtual channels include: One or more trigger ports, the one or more trigger ports being configured to be coupled to the external source device or the external destination device; and A control finite state machine (FSM) is configured to control direct memory access (DMA) commands in the virtual channel in response to signals on one or more trigger ports.

4. The Direct Memory Access Controller (DMAC) of claim 3, wherein the control FSM of the virtual channel is further configured to generate the flow control signal based at least in part on a signal from one or more of the trigger ports.

5. The Direct Memory Access Controller (DMAC) of claim 3, wherein the context manager includes deallocation logic, and wherein the control FSM of the virtual channel is configured to signal the context manager when the virtual channel is in a state in which it can be deallocated by the context manager.

6. The Direct Memory Access Controller (DMAC) according to claim 1, wherein: The context manager is configured to send a preemptive pause request to the lowest priority virtual channel when a higher priority virtual channel is unable to access the physical channel because a lower priority virtual channel is unable to perform its operation; and The lowest priority virtual channel is configured to forward the preemptive pause request to the physical channel assigned to it.

7. The Direct Memory Access Controller (DMAC) of claim 1, wherein the physical channel in the one or more physical channels comprises: The command descriptor storage area configured to store command parameters; Command descriptor update logic configured to update one or more command parameters among the command parameters stored in the command descriptor storage area; and A context fetching and saving finite state machine (FSM) configured to transfer command parameters between the command descriptor storage area and the context memory.

8. The Direct Memory Access Controller (DMAC) of claim 7, wherein the command parameters include source address and destination address, source address increment and destination address increment, data block size and number of pending transfers.

9. The direct memory access controller (DMAC) of claim 7, further comprising a DMA control logic block, the DMA control logic block being configured to: When a virtual channel is deallocated, all channel registers associated with the execution of the DMA command are cleared; and Generate a write command to clear the associated region in the context memory.

10. The direct memory access controller (DMAC) of claim 7, wherein the context memory is coupled to the DMAC via a bus, the DMAC further comprising a context bus interface unit coupled to one or more physical channels, the context bus interface unit comprising: Bus arbitration logic configured to arbitrate bus access requests from multiple physical channels; and Transmission generation logic configured to generate bus requests corresponding to requests received from the physical channel.

11. The Direct Memory Access Controller (DMAC) of claim 1, further comprising a DMA control logic block, the DMA control logic block comprising: DMAC global control logic; It is configured as a bus interface for exchanging configuration data with external hardware. An interface to the virtual and physical channel configuration registers; and A bridge that enables the external hardware to access the context memory to the context bus interface unit.

12. The Direct Memory Access Controller (DMAC) of claim 11, wherein the DMA control logic block further comprises an interrupt controller configured to collect DMA channel status signals from the virtual channel and generate an interrupt signal on an associated channel on the interrupt bus based on the DMA channel status signals.

13. The direct memory access controller (DMAC) of claim 1, wherein the external source device and the external destination device are coupled to the DMAC via a data bus, the DMAC further comprising a data bus interface unit coupled to one or more physical channels, the data bus interface unit comprising: Bus arbitration logic configured to arbitrate bus access requests from multiple physical channels; Transmission generation logic configured to generate bus requests corresponding to requests received from the physical channel; and A buffer configured to store data read from the external source device and to be written to the external destination device.

14. The Direct Memory Access Controller (DMAC) of claim 1, wherein the routing logic of the context manager includes: An allocation table maintained by the arbitration logic, wherein each entry in the allocation table corresponds to a physical channel and indicates which virtual channel the physical channel is allocated to; For each of the one or more physical channels, the virtual-to-physical multiplexer is configured to select a virtual channel from the plurality of virtual channels according to the entry for the physical channel in the allocation table, and to route signals from the selected virtual channel to the physical channel; and For each of the one or more physical channels, the physical-to-virtual multiplexer is configured to select a virtual channel from the plurality of virtual channels based on the entry for the physical channel in the allocation table, and to route signals from the physical channel to the selected virtual channel.

15. A method for data transmission in a data processing system, comprising: The context manager of the Direct Memory Access Controller (DMAC) allocates a physical channel from one or more virtual channels of the DMAC to a selected virtual channel from the plurality of virtual channels in response to an allocation request from the DMAC. as well as Flow control signals are generated from the selected virtual channel; Data transfer from one or more source addresses in an external source device to one or more destination addresses in an external destination device is initiated by one or more physical channels of the DMAC in response to the flow control signal, according to the command descriptor for the DMA channel; The context manager routes the flow control signals from the selected virtual channel to the assigned physical channel; as well as The context manager routes status signals from the assigned physical channel to the selected virtual channel.

16. The method of claim 15, further comprising the command descriptor by which the DMA channel is configured by external hardware.

17. The method of claim 15, wherein the command descriptor includes the following as command parameters: Source address and destination address; Source address increment and destination address increment; Data block size; and The number of data blocks to be transferred between the external source device and the external destination device.

18. The method of claim 15, wherein generating the flow control signal by the selected virtual channel is in response to one or more trigger inputs from the external source device, the external destination device, or both the external source device and the external destination device.

19. The method of claim 15, further comprising: The channel register is cleared when a specified bit in the header of the command descriptor is set.

20. The method of claim 15, wherein the dispensing comprises: The virtual channel is selected at least in part based on the priority value of the virtual channel among the requested allocation of the plurality of virtual channels; Select a physical channel from the one or more physical channels that is neither assigned nor in the process of being assigned. as well as The identifier of the selected virtual channel is stored in the entry of the allocation table corresponding to the selected physical channel.

21. The method of claim 20, wherein the routing includes controlling the multiplexer of the DMAC according to the entries in the allocation table.

22. The method of claim 15, further comprising: responding to a change in the allocation of a physical channel: Save the current context of the physical channel to the context memory; and Retrieve a new context for the physical channel from the context memory.

23. The method of claim 22, wherein saving or retrieving the context includes accessing an external context memory via a bus.

24. The method of claim 15, further comprising: in response to completing data transmission from the source external device to the destination external device according to the first command descriptor: Reload the first command descriptor; Load the second command descriptor; or Release the physical channel.

25. A non-transitory computer-readable medium storing computer-readable code for manufacturing a direct memory access controller (DMAC), the direct memory access controller (DMAC) comprising: Multiple virtual channels, one of which is configured to generate flow control signals for executing direct memory access (DMA) commands; One or more physical channels, wherein one of the physical channels includes read and write control logic, the read and write control logic being used to initiate data transmission from a source address in an external source device to a destination address in an external destination device in response to the flow control signal according to the DMA command; and Context manager, the context manager including: Allocation logic, configured to arbitrate allocation requests from the plurality of virtual channels, and to allocate a physical channel from the one or more physical channels to a selected virtual channel from the plurality of virtual channels; and The routing logic is configured to route flow control signals from the selected virtual channel to the assigned physical channel, and to route status signals from the assigned physical channel to the selected virtual channel.

Images