Unified dma

Unified DMA

BACKGROUND

Field of the Invention

This invention relates to the field of integrated circuits and, more specifically, to direct memory access (DMA) in systems comprising one or more integrated circuits.

Description of the related technique

In a typical system that includes one or more processors, memory and input / output (I / O) devices or interfaces, direct access to memory (DMA) transfers are often used to transfer data between the I / O and the memory. In some systems, individual DMA circuits are included in each device or I / O interface used by the DMA. In other systems, one or more I / O devices can share DMA circuits.

Some systems also include a "data carrier" that can be used to copy data from one memory area to another. The data carrier can download the processors, otherwise they would have to execute instructions to carry out the data movement (for example, read and write data with the width used by the processor, usually 32 bits or 64 bits at the time). The programming model for the data carrier is usually different from the DMA programming model, which is conditioned for communication between I / O devices and memory.

US 2004/0064600 A1 discloses a disk controller with direct memory access used in hardware-assisted data transfer operations, which includes command-receiving logic to receive a data transfer command issued by a processor. WO 2004/010314 A2 provides a method, system and program for a local bus system coupled with a port, which is associated with a memory address space.

SUMMARY OF THE INVENTION

In one embodiment, an apparatus comprises a first interface circuit, a direct memory access controller (DMA) coupled with the first interface circuit and a host coupled with the DMA controller. The first interface circuit is configured to communicate by an interface according to a protocol. The host comprises at least one address space mapped, at least in part, to a plurality of memory locations in a host memory system. The DMA controller is configured to carry out DMA transfers between the first interface circuit and the address space, and the DMA controller is additionally configured to carry out DMA transfers between a first plurality of the plurality of locations of memory and a second plurality of the plurality of memory locations. A procedure is also contemplated.

The invention is as defined by the attached independent claims 1 and 9.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description refers to the attached drawings, which are now briefly described.

Fig. 1 is a block diagram of an embodiment of a system.

Fig. 2 is a block diagram of an embodiment of a DMA controller shown in Fig. 1.

Fig. 3 is a block diagram of an embodiment of a discharge motor shown in Fig. 2.

Fig. 4 is a block diagram of an embodiment of the DMA in the system of Fig. 1.

Fig. 5 is a block diagram of an embodiment of descriptor rings and intermediate memory pointer rings.

Fig. 6 is a flow chart illustrating the operation of an embodiment of a receiving pre-capture engine shown in Fig. 2.

Fig. 7 is a flow chart illustrating the operation of an embodiment of a reception control circuit shown in Fig. 2.

Fig. 8 is a flowchart illustrating the precapture operation of an embodiment of a transmission control circuit shown in Fig. 2.

Fig. 9 is a flow chart illustrating the transmission operation of an embodiment of a transmission control circuit shown in Fig. 2.

Fig. 10 is a block diagram illustrating a descriptor ring with a control descriptor included with the transfer descriptors.

Fig. 11 is a flow chart illustrating an embodiment of the control descriptor processing.

Fig. 12 is a block diagram illustrating an embodiment of a receiving DMA descriptor.

Fig. 13 is a block diagram illustrating an embodiment of a transmission DMA descriptor.

Fig. 14 is a block diagram illustrating an embodiment of a DMA copy descriptor.

Fig. 15 is a block diagram of an embodiment of a DMA download descriptor.

Fig. 16 is a block diagram of an embodiment of a control descriptor.

Fig. 17 is a block diagram of an embodiment of a control sum generator shown in Fig. 3.

Fig. 18 is a block diagram of an embodiment of a complete adder shown in Fig. 17.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the drawings and detailed description thereof are not intended to limit the invention to the specific form disclosed, but, on the contrary, the intention is to cover all modifications, equivalents and alternatives that fall within of the spirit and scope of the present invention, as defined by the appended claims.

DETAILED DESCRIPTION

Turning now to Fig. 1, a block diagram of an embodiment of a system 10 is shown. In the illustrated embodiment, the system 10 includes a host 12, a DMA controller 14, interface circuits 16 and a physical interface layer (PHY) 36. DMA controller 14 is coupled with host 12 and interface circuits 16. The interface circuits 16 are additionally coupled with the physical interface layer 36. In the illustrated embodiment, host 12 includes one or more processors such as processors 18A-18B, one or more memory controllers such as memory controllers 20A-20B, an I / O bridge (IOB) 22, a memory of I / O (IOM) 24, a temporary I / O memory (IOC) 26, a temporary memory 28 of level 2 (L2) and an interconnection 30. Processors 18A-18B, memory controllers 20A-20B, the IOB 22 and the temporary memory 28 of L2 are coupled with the interconnection 30. The IOB 22 is additionally coupled with the IOC 26 and the IOM 24. The DMA controller 14 is also coupled with the IOB 22 and the IOM 24. In the illustrated embodiment, the interface circuits 16 include an interface controller 32 peripheral and one or more media access control (MAC) circuits, such as MAC 34A34B. The MAC 34A-34B are coupled with the DMA controller 14 and with the physical interface layer 36. The peripheral interface controller 32 is also coupled with the I / O bridge 22 and the I / O memory 34 (and therefore indirectly coupled with the DMA controller 14) and with the physical interface layer 36. Both peripheral interface controller 32 and MAC 34A-34C include configuration records 38A-38C. In some embodiments, system components 10 can be integrated over a single integrated circuit, such as a system on a chip. In other embodiments, the system 10 can be implemented as two or more integrated circuits.

Host 12 may comprise one or more address spaces. At least a portion of an address space on host 12 may be mapped to memory locations on host 12. That is, host 12 may comprise a memory system mapped to addresses in the host's address space. For example, each of the memory controllers 20A-20B can be coupled with memory (not shown) comprising memory locations mapped in the address space. In some cases, the entire address space can be mapped to memory locations. In other cases, some of the address space may be memory mapped I / O (for example, the peripheral interface controlled by the peripheral interface controller 32 may include some memory mapped I / O).

The DMA controller 14 is configured to carry out DMA transfers between the interface circuits 16 and the host address space. In particular, DMA transfers can be between memory locations to which the address space and interface circuits 16 are mapped. Additionally, the DMA controller 14, in some embodiments, can be configured to perform DMA transfers between sets of memory locations within the address space. That is, both the origin and the destination of such a DMA transfer can be memory locations. The functionality of a data carrier may therefore be incorporated into the DMA controller 14, and a different data carrier may not be required, in some embodiments. The programming model for DMA transfers from memory to memory may be similar to the programming model for other DMA transfers (for example, DMA descriptors, described in more detail below). A DMA transfer from memory to memory can also be called a DMA copy transfer.

The DMA controller 14 may be configured to perform one or more operations (or "functions") on the DMA data as the DMA data is being transferred, in some embodiments. The operations can be carried out on transfers between the address space and the interface circuits, and can also be carried out on DMA copy transfers, in some embodiments. The operations carried out by the DMA controller 14 can reduce the processing load on the processors 18A-18B, in some embodiments, since the processors do not need to carry out the operations carried out by the DMA controller 14 . In one embodiment, some of the operations carried out by the DMA controller 14 are operations on packet data (for example, encryption / decryption, generation or verification of the cyclic redundancy control, generation or verification of the checksum , etc.). The operations may also include an exclusive O operation (XOR), which can be used for processing redundant cheap disk formations (RAID), for example.

In general, DMA transfers can be data transfers from a source to a destination, where at least one of the destinations is a memory location or other address (s) in the host's address space. DMA transfers are made without transferring data through the processor, or processors, in the system (for example, processors 18A-18B). DMA controller 14 can make DMA transfers by reading at the source and writing at the destination. For example, a transfer of DMA from the memory to an interface circuit 16 can be performed by the DMA controller 14, generating memory read requests (to IOB 22, in the illustrated embodiment, which carries out transactions of consistent reading on interconnection 30 to read the data) and transmitting the read data as DMA data to the interface circuit 16. In one embodiment, the DMA controller 14 may generate read requests to read data in the IOM 24 for a DMA transfer through the peripheral interface controller 32, and the peripheral interface controller 32 may read the data from the IOM 24 and transmit the data. A transfer of DMA from an interface circuit 16 to the memory can be performed by the DMA controller 14, receiving data from the interface circuit 16 and generating write-in-memory requests (to IOB 22, in the illustrated embodiment) to transfer DMA data to memory. In one embodiment, the peripheral interface controller 32 may write data to IOM 24, and the DMA controller 14 may cause the data to be written to memory. Thus, DMA controller 14 can provide DMA assistance for peripheral interface controller 32. DMA copy transfers can be made by generating memory read requests for source memory locations and memory write requests for destination memory locations (including DMA data from memory read requests).

Host 12 may, in general, comprise one or more memory processors and controllers, configured to maintain interfaces with the memory mapped in the address space of host 12. Host 12 may optionally include other circuits, such as memory temporary 28 of L2, to improve the performance of the processors on host 12. In addition, host 12 may include circuit system to maintain interfaces with various I / O circuits and DMA controller 14. While an implementation of host 12 is illustrated in Fig. 1, other embodiments may include any construction and interface with controller 14 and interface circuits 16.

Processors 18A-18B comprise circuit system for executing instructions defined in an architecture of a set of instructions implemented by processors 18A to 18B. Any instruction set architecture can be implemented in various embodiments. For example, the PowerPC ™ instruction set architecture can be implemented. Other example architectures of instruction sets may include the ARM ™ instruction set, the MIPS ™ instruction set, the SPARC ™ instruction set, the x86 instruction set (also called 1A-32), the instruction set 1A-64, etc.

Memory controllers 20A-20B comprise circuit system configured to maintain interfaces with memory. For example, memory controllers 20A-20B can be configured to maintain interfaces with dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM), dual data rate SDRAM (DDR), DDR2 SDRAM, DRAM Rambus (RDRAM), etc. Memory controllers 20A-20B can receive read and write transactions for the memory with which they are coupled from interconnection 30, and can perform read / write operations in memory. Read and write transactions may include read and write transactions initiated by IOB 22 for the benefit of DMA controller 14 and / or peripheral interface controller 32. Additionally, read and write transactions may include transactions generated by processors 18A-18B and / or temporary memory 28 of L2.

The temporary memory 28 of L2 may comprise a temporary memory configured to temporarily store copies of data corresponding to various memory locations in the memories with which memory controllers 20A-20B are coupled, for low latency access by the users. 18A-18B processors and / or other agents, by interconnection 30. The temporary memory 28 of L2 can comprise any capacity and configuration (for example, directly mapped, associative by sets, etc.).

The IOB 22 comprises circuit system configured to communicate transactions over the interconnection 30 for the benefit of the DMA controller 14 and the peripheral interface controller 32. Interconnection 30 can support the consistency of temporary memory, and IOB 22 can participate in consistency and ensure consistency of transactions initiated by IOB 22. In the illustrated embodiment, IOB 22 employs IOC 26 to temporarily store recent transactions initiated by IOB 22. IOC 26 can have any capacity and configuration, in various embodiments, and can be consistent. IOC 26 can be used, e.g. eg, to temporarily store blocks of data that are only partially updated, due to readings / writes generated by DMA controller 14 and peripheral interface controller 32. Using IOC 26, read-modify-write sequences can be avoided by interconnection 30, in some cases. Additionally, interconnection transactions 30 can be avoided for a temporary memory match in IOC 26, for a read / write generated by DMA controller 14 or peripheral interface controller 32 if IOC 26 has sufficient ownership power over the temporary memory block to complete the reading / writing. Other embodiments may not include IOC 26.

IOM 24 can be used as a hosting buffer for data that is being transferred between IOB 22 and peripheral interface 32 or DMA controller 14. Thus, the data path between IOB 22 and DMA controller 14, or peripheral interface controller 32, may be through IOM 24. The control path (including read / write requests, addresses in the host address space associated with the requests, etc.) can be directly between the IOB 22 and the DMA controller 14 / peripheral interface controller 32. IOM 24 may not be included in other embodiments.

The interconnection 30 may comprise any means of communication for communicating between the processors 18A18B, the memory controllers 20A-20B, the temporary memory 28 of L2 and the IOB 22. For example, the interconnection 30 may be a bus with coherence support. The interconnection 30, alternatively, may be a point-to-point interconnection between the above agents, a packet-based interconnection, or any other interconnection.

The interface circuits 16 generally comprise circuits configured to communicate by an interface with the system 10 according to any interface protocol, and to communicate with other components in the system 10 to receive communications to be transmitted by the interface, or to provide communications received from the interface. Interface. The interface circuits may be configured to convert the communications originating in the system 10 to the interface protocol, and to convert the communications received from the interface for transmission in the system 10. For example, the interface circuits 16 may comprise circuits configured for communicate according to a peripheral interface protocol (for example, peripheral interface controller 32). As another example, the interface circuits 16 may comprise circuits configured to communicate according to a network interface protocol (for example, MACs 34A to 34B).

The MAC 34A-34B may comprise circuit system that implements the functionality of the media access controller defined for network interfaces. For example, one or more of the MAC 34A-34B can implement the Gigabit Ethernet standard. One or more of the MAC 34A-34B can implement the 10 Gigabit Ethernet Annexation Interface (XAUI) standard. Other embodiments may implement other Ethernet standards, such as the 10 Megabit or 100 Megabit standards, or any other network standard. In one implementation, there are 6 MACs, 4 of which are Gigabit Ethernet MACs and 2 of which are XAUI MACs. Other embodiments may have more or less MAC, and any mixture of MAC types.

Among other things, MAC 34A-34B that implement Ethernet standards can rule out the gap between frames (IFG), the preamble and the beginning of the frame delimiter (SFD) of the received packets, and can provide the remaining packet data to the DMA controller 14 for DMA to memory. The MAC 34A-34D can be configured to insert the IFG, the preamble and the SFD for packets received from the DMA controller 14 as a transmission DMA transfer, and can transmit the packets to the PHY 36 for transmission.

The peripheral interface controller 32 comprises circuit system configured to control a peripheral interface. In one embodiment, the peripheral interface controller 32 may control a Peripheral Component Interconnect (PCI) Express Interface. Other embodiments may implement other peripheral interfaces (for example, PCI, PCI-X, universal serial bus (USB), etc.), in addition, or instead, to the PCI Express interface.

The PHY 36 may comprise, in general, the circuit system configured to physically communicate, via the external interfaces, with the system 10, under the control of the interface circuits 16. In a specific embodiment, the PHY 36 may comprise a set of serializer / deserializer circuits (SERDES) that can be configured for use as PCI Express paths or as Ethernet connections. The PHY 36 may include the circuit system that carries out the coding / decoding 8b / 10b for transmission through the SERDS and synchronization buffers 'first to enter, first to exit' (FIFO), and also the circuit system that logically configures SERDES links for use as PCI or Ethernet Express communication links. In one implementation, the PHY may comprise 24 SERIES that can be configured as PCI Express paths or Ethernet connections. Any desired number of SERDES can be configured as PCI Express and any desired number can be configured as Ethernet connections.

In the illustrated embodiment, the configuration records 38A-38C are shown in the peripheral interface controller 32 and the MAC 34A-34B. There may be one or more configuration records in each of the peripheral interface controllers 32 and the MAC 34A-34B. There may also be other configuration registers in system 10, not shown in Fig. 1. The configuration registers can be used to configure various programmable selectable features of the peripheral interface controller 32 and the MAC 34A-34B, enable or disable various features, configure the peripheral interface controller 32 and the MAC 34A-34B for operation, etc. In an embodiment described below, the configuration records can be specified in a control descriptor for the on-the-fly reconfiguration of the peripheral interface controller 32 and the MAC 34A-34B.

It is noted that, in various embodiments, the system 10 may include one, or any number, of any of the elements shown in Fig. 1 (for example, processors, memory controllers, temporary memories, I / O bridges , DMA controllers and / or interface circuits, etc.).

Turning now to Fig. 2, a block diagram of an embodiment of the DMA controller 14 is shown. For the embodiment of Fig. 2, a descriptor software model for making DMA transfers will be exposed. In some embodiments, a software model based on records may be supported, in addition to, or instead, the descriptor model. In a record-based model, each DMA transfer can be programmed into the DMA controller 14, and the DMA controller 14 can carry out the DMA transfer. Upon completion of the transfer, the DMA controller 14 may either interrupt one of the processors 18A-18B, or provide the status (for example, in a register within the DMA controller 14) that the software can poll to determine when You have completed the DMA transfer.

In the descriptor model, the software can establish multiple DMA transfers to be carried out, using descriptor data structures in memory. In general, a DMA descriptor may comprise a data structure in memory that describes a DMA transfer. The information in the DMA descriptor, for example, can specify the origin and destination of the DMA transfer, the size of the transfer and various attributes of the transfer. In some cases, the origin or destination of the DMA transfer may be implicit. Multiple descriptors can be stored in a descriptor data structure in memory (for example, in a "descriptor ring"), and the DMA controller 14 can be programmed with the address of the first descriptor in the data structure. The DMA controller 14 can read the descriptors and carry out the indicated DMA transfers. A wide variety of control mechanisms can be used to control the property of the descriptors between the software and the hardware. For example, the descriptors may include validation bits or enable bits that indicate to the DMA controller 14 that the DMA transfer described in the descriptor is ready to be carried out. An interrupt bit in a descriptor can be used to indicate that the DMA controller 14 is to interrupt the processor 18A to 18B at the end of a given DMA transfer, or an end of transfer bit can be used to indicate that the descriptor describes the last DMA transfer and that the DMA controller 14 should pause. Alternatively, the DMA controller 14 may implement descriptor counter registers that can be incremented by the software to indicate how many descriptors are available for processing by the DMA controller 14. The DMA controller 14 may decrement a descriptor counter register to indicate that a descriptor precapture has been generated. In other embodiments, the DMA controller 14 may decrement the descriptor counter register to indicate the consumption of a descriptor (ie, the execution of the specified DMA transfer). In other additional embodiments, the DMA controller 14 may use a record other than the descriptor processed counter to indicate how many descriptors have been processed or pre-captured.

The DMA controller 14 can carry out transmission DMA transfers (Tx) and receive DMA transfers (Rx). DMA Tx transfers have an address space on host 12 as the source (for example, memory locations in memory coupled with memory controllers 20A-20B). DMA Rx transfers have an address space on host 12 as the destination. The DMA Tx transfers may have an interface circuit 16 as the destination, or they may have another address in the address space of the host 12 as the destination (for example, for DMA copy transfers). DMA Tx transfers that have host address space destinations can use the DMA Rx data path to write the DMA data read from the source address to the destination address. A test loop circuit 40 may provide the link between the data path of the DMA Tx and the data path of the DMA Rx. That is, a "test loop circuit" comprises local circuits to the DMA controller that is coupled to receive data from DMA Tx from a data path of the transmission DMA and to provide data from the DMA Rx by a data path of the DMA. of reception. The data provided by the test loop circuit 40 in the data path of the receiving DMA may be the data received from the data path of the transmission DMA (for example, for the DMA copy function). In some embodiments, the data provided by the test loop circuit 40 may be data transformed by the test loop circuit 40 from the received data. In some embodiments, the data provided by the test loop circuit 40 may be the data received by the test loop circuit 40, augmented by a result calculated by the test loop circuit 40 over the data (for example , checksum, CRC data, etc.). Alternatively, the data provided by the test loop circuit 40 may be the data received by the test loop circuit 40 (or the data may not be provided), and the result may be stored in the descriptor for DMA transfer. . Either the transformed data, or the result calculated and included with the data, or written in the DMA descriptor, can be generically referred to herein as the "result."

Thus, in some embodiments, the test loop circuit 40 may be configured to perform one or more operations (or "functions") on the DMA Tx data in order to produce a result (eg, DMA data transformed, or a result generated from the data). In the embodiment of Fig. 2, the test loop circuit 40 may include a copy FIFO 42, a download motor 44 and an exclusive O-circuit 46 (XOR) coupled with the transmission data path. The copy FIFO 42 may store transmission data from the DMA Tx data path, for transmission by the DMA Rx data path. Consequently, copy FIFO 42 can carry out the copy operation of the DMA. The download engine 44 can be configured to perform various operations on the DMA data, producing either transformed data or a result other than the data. The unloading motor 44 can be configured to provide any desired set of operations, in various embodiments. In one embodiment, the unloading engine 44 can be configured to carry out operations that help packet processing. For example, various network security protocols have been developed that provide encryption and / or packet authentication. Authentication usually includes generating a mapping on some, or all, of the package. Therefore, the download engine 44 can be configured to perform encryption / encryption and / or packet data mapping functions in a DMA transfer. Additionally, the unloading engine 44 may be configured to carry out the generation / verification of checksums and / or the generation / testing of the CRC. The sum of control and / or CRC protection are used in various packet protocols. The XOR 46 circuit can perform the bit-by-bit XOR operation on DMA data (for example, DMA data from multiple sources). The XOR 46 circuit can be used, e.g. eg, to support the processing of redundant formations of cheap disks (RAID) and other types of processing that use XOR functions.

The test loop circuit 40 (and, more specifically, the test loop components 42, 44 and 46) may operate on the DMA data during the DMA transfer that provides the DMA data to the test loop circuit 40 . That is, the test loop circuit 40 can at least begin to carry out the operation on the DMA data while the DMA transfer Tx provides the rest of the DMA data. In general, the result can be written in memory or, more generally, in the host address space (for example, as transformed DMA data, attached to the DMA data, or to a different location of results memory, such as a field in the DMA descriptor for the transfer of DMA Tx).

The test loop circuit 40 may also include FIFOs for the discharge motor 44 and the XOR 46 circuit (discharge FIFO 48 coupled with the discharge motor 44 and XOR FIFO 50 coupled with the XOR circuit 46). FIFOs 48 and 50 may temporarily store data from the download engine 44 and the XOR circuit 46, respectively, until the DMA data can be transmitted through the reception DMA data path. An arbitrator 52 is provided in the illustrated embodiment, coupled with FIFOs 42, 48 and 50, to arbitrate between FIFOs. The arbitrator 52 is also coupled with a test loop FIFO 54, which can temporarily store data from the test loop circuit 40 to be written to the destination.

In the illustrated embodiment, the DMA controller 14 comprises a Tx control circuit 56 in the DMA Tx data path, and a Rx control circuit 58 in the DMA Rx data path. The Tx control circuit 56 can pre-capture data from host 12 for transmission DMA transfers. In particular, control circuit 56 Tx can pre-capture DMA descriptors, and can process DMA descriptors to determine the source address for DMA data. The control circuit 56 Tx can then pre-capture the DMA data. While the term precapture is used to refer to the operation of the Tx control circuit 56, the precaptures can generally be read operations generated to read the descriptor and DMA data from the host address space.

The Tx control circuit 56 transmits DMA data to the destination. The destination, in this embodiment, may be either one of the interface circuits 16 or the test loop circuit 40 (and, more specifically, one between the copy FIFO 42, the discharge motor 44 and the XOR circuit 46 in the illustrated embodiment). The control circuit 56 Tx can identify the destination for the transmitted data (for example, by transmitting a destination identifier). Alternatively, physically different paths can be provided between control circuit 56 Tx and interface circuits 16 and between control circuit 56 Tx and test loop components 42, 44 and 46. The control circuit 56 Tx may include a set of buffers 62 to temporarily store data to be transmitted. The control circuit 56 Tx can also provide various control information with the data. Control information may include information from the DMA descriptor. The control information may include, for the test loop circuit 40, the intermediate memory pointer (s) for storing data in the destination address space. The control information may also include any other control information that may be included in the DMA descriptor and may be used by the interface circuits 16 or the test loop circuit 14. Examples will be provided in more detail below, regarding the exposure of the DMA descriptor.

The control circuit 58 Rx can receive DMA data to be written in the address space of the host 12, and can generate writes to store the data in memory. In one embodiment, the software can allocate buffers in memory to store the received DMA data. The control circuit 58 Rx can be provided with intermediate memory pointers (addresses in the host address space that identify the intermediate memories). The control circuit 58 Rx can use the buffer pointer to generate the addresses for the writes in order to store the data. An Rx precapture motor 60 can be provided to pre-buffer the intermediate memory pointers for the Rx control circuit 58. The Rx precapture engine 60 is coupled to provide the intermediate memory pointers to the Rx control circuit 58. The Rx precapture engine 60 may include a set of buffers 64 for temporarily storing pointers of captured buffers, for use by the Rx precapture engine 60. Similarly, the control circuit 58 Rx may include a set of buffers 68 to temporarily store the received DMA data, to be written into memory.

In one embodiment, the Rx control circuit 58 can be configured to generate descriptors for the received DMA data. That is, instead of having the software create DMA descriptors for received DMA data, the software can allocate buffers to store the DMA data and can provide the buffer pointers. The control circuit 58 Rx can store the received DMA data in the allocated buffers, and can create the descriptors for the DMA transfers. The descriptors created by the Rx control circuit 58 may include one or more buffer pointers to one or more buffers that store the received DMA data, as well as other information describing the DMA transfer. An exemplary embodiment of the receiving DMA descriptor is shown in Fig. 12 and is described in more detail below. Since the Rx control circuit 58 creates the descriptors for the received DMA data, the descriptors may be more efficient than those created by the software. For example, the software may have to create receiving DMA descriptors capable of receiving the largest possible DMA transfer (or multiple descriptors may be required for larger transfers), and may have to allocate sufficient buffers to store the largest possible DMA transfer. . On the other hand, the descriptors created by the control circuit Rx may be large enough for the actual transfer received (and may consume enough buffers to store the received data), but not necessarily larger.

In the illustrated embodiment, the Rx control circuit 58 can receive the DMA data from an arbitrator 66, which is coupled with the test loop FIFO 54 and also to receive DMA data from the interface circuits 16. The arbitrator 66 may arbitrate between the FIFO 54 loop test and the DMA data received from the interface circuits 16 to transfer data to the control circuit 58 Rx.

Arbitrators 52 and 66 may implement any desired arbitration scheme. For example, a priority-based scheme, a circular batch scheme, a weighted circular batch scheme, or combinations of such schemes can be used. In some embodiments, the arbitration scheme can be programmable. The scheme, or the schemes, implemented (s) by the arbitrator 52 may differ from the scheme, or schemes, implemented (s) by the arbitrator 66.

The control circuit 56 Tx, the precaution motor 60 Rx and the control circuit 58 Rx are coupled with an IOM / IOB interface unit 70 in the illustrated embodiment. The IOM / IOB interface unit 56 can communicate with the IOB 22 and IOM 24 for the benefit of the control circuit Tx 56, the precautionary motor 60 Rx and the control circuit 58 Rx. The IOM / IOB interface unit 70 can receive read and write requests from the Tx control circuit 56, the Rx precapture motor 60 and the Rx control circuit 58, and can communicate with the IOB 22 and IOM 24 to Satisfy those requests.

In particular, the IOM / IOB interface unit 70 can receive read requests for descriptors and for DMA data from the Tx control circuit 56, and read requests for the memory that stores intermediate memory pointers from the engine 60 precapture Rx, and can take requests to IOB 22. The IOB 22 may indicate which entry of the IOM 24 stores a line of temporary data memory that includes the requested data (after reading the data from the host address space or the IOC 26, for example, or data may already be in the IOM 24 from a previous request), and the IOM / IOB interface 70 can read the data from the IOM 24 and provide it to the control circuit 56 Tx or the precaution motor 60 Rx. The IOM / IOB interface unit 70 can also receive write requests from the Rx control circuit 58, and can store the write data in the IOM 24 (in an input allocated for the write data by the IOB 22). Once a line of temporary data memory is accumulated in IOM 24 (or DMA transfer is completed, whichever comes first), IOM / IOB interface unit 70 can inform IOB 22 and can provide a address to which the temporary memory line is to be written (obtained from the intermediate memory pointer to the intermediate memory in which it is being written).

In one embodiment, the DMA controller 14 may support various channels for transmitting DMA transfers and receiving DMA transfers. Any number of channels can be supported, in various embodiments. For example, in one implementation, 20 broadcast DMA channels can be provided and 64 receive DMA channels can be provided. Each channel can be an independent logical path of data from a source to a destination. Channels can be allocated as desired by the software.

More specifically, each transmission channel can be assigned to one of the interface circuits 16, or to one of the test loop component circuits 42, 44 or 46. Not all transmission channels must be in use (that is, some transmission channels may be disabled). The Tx control circuit 56 can pre-capture DMA descriptors and DMA data channel by channel. That is, the Tx control circuit 56 can independently generate pre-captures for each channel that has DMA descriptors available for processing. The Tx control circuit 56 may select among the generated pre-captures to transmit read requests to the IOM / IOB interface unit 70.

Each reception channel can be assigned to one of the interface circuits 16. Not all reception channels must be in use (that is, some reception channels may be disabled). The control circuit 58 Rx can receive the channel number with the received data. The test loop circuit 40 may provide an intermediate memory pointer from the DMA descriptor for the DMA, and the Rx control circuit 58 may use the intermediate memory pointer to write the DMA data in the host address space . The interface circuits 16 can be programmable with the assigned channels, or they can use packet filtering to determine a channel. The interface circuits 16 may provide the channel number with the DMA data, and the Rx control circuit 58 may use an intermediate memory pointer provided from the Rx precapture engine 60 for the channel, to write the DMA data in The host address space.

The DMA controller 14 may include various configuration records 38D-38H, as shown in Fig. 2. The configuration records 38D-38H may be programmable to enable / disable various programmable features of the DMA controller 14 and / or to Configure the programmable features, as mentioned above. For example, the configuration records 38D in the control circuit 56 Tx may include descriptor ring addresses for each channel, as well as descriptor counters indicating the number of available descriptors. The configuration records 38D may additionally include assignments of transmission channels to interface circuits 16 and test loop component functions. Several other configurations per channel and configurations not linked to channels can be stored in the configuration records 38D. Similarly, configuration registers 38E can store ring addresses of intermediate memory pointers for each interface circuit 16, intermediate memory ring counters, etc., as well as various configurations not linked to channels. Configuration records 38F can store various receiving DMA configurations. The configuration registers 38G can store configurations for the test loop circuit 40 as a whole, as well as configurations for each component circuit, as desired. The configuration records 38G can also store configurations for the arbitrator 52 (for example, selection of the arbitration scheme, programming configuration for the selected arbitration scheme). Configuration records 38H may store arbitration configurations for arbitrator 66.

It is noted that, while the Tx control circuit 56 implements the pre-capture to obtain descriptors and DMA data, other embodiments may not implement the pre-capture. Thus, in general, there may be a 56 Tx engine or a Tx control circuit 56 configured to carry out transmission DMA transfers (and DMA transfers to the test loop circuit 40).

It is noted that the present description refers to buffers and buffers for DMA transfers. An intermediate memory pointed to by an intermediate memory pointer (as opposed to hardware buffers such as 62, 64 and 68) may comprise a region of contiguous memory. The software can allocate the memory region to store DMA data (either for transmission or as a region to receive DMA data). The buffer pointer may comprise an address of the memory region in the host address space. For example, the buffer pointer may point to the base of the memory region or to the limit of the memory region.

Turning now to Fig. 3, a block diagram of an embodiment of the discharge motor 44 is shown. In the illustrated embodiment, the discharge engine 44 includes an input buffer 80, an output buffer 82, a set of safety circuits 84A-84D, a CRC generator 86 and a control sum generator 88 . The input buffer 80 is coupled with the control circuit 56 Tx and with the safety circuits 84A-84D, the CRC generator 86 and the control sum generator 88. The output buffer 82 is coupled with the safety circuits 84A-84D, the CRC generator 86 and the control sum generator 88. The output buffer 82 is also coupled with the download FIFO 48. Safety circuit 84A is shown in greater detail in Fig. 3 for one embodiment, and the security circuits 84B-84D may be similar. The security circuit 84A includes a mapping circuit 90 and an encryption circuit 92. Both the mapping circuit 90 and the encryption circuit 92 are coupled with the input buffer 80 and the output buffer 82. Additionally, the output of the mapping circuit 90 is coupled as an input to the encryption circuit 92, and the output of the encryption circuit 92 is coupled as an input to the mapping circuit 90 in a "butterfly" configuration.

The security circuits 84A-84D can be configured to perform various operations in order to download security functions from packet processing. In particular, security circuits 84A-84D can be configured to perform encryption / encryption (collectively referred to as encryption, or encryption functions) and mapping functions that are included in various specifications of secure packets (for example, the protocol Internet secure (IPSec) or the secure watershed layer (SSL).

Usually, the communication using a secure packet protocol includes a negotiation session in which the endpoints communicate the protocols they can use, the security schemes they support, the type of encryption and mapping, the exchange of keys or certificates, etc. Then there is a bulk transfer phase that uses the agreed protocols, encryption, etc. During bulk transfer, packets can be received on host 12 (for example, via the receiving DMA path from one of the interface circuits 16). The software can query data structures in memory to obtain the keys, encryption algorithms, etc., and prepare a DMA transfer through the download engine 44 to encrypt and / or authenticate the package. Similarly, the software can prepare a packet for secure transmission and use a DMA transfer through the download engine 44 to encrypt and / or authenticate the packet.

The mapping circuit 90 can implement various mapping functions that can be used in packet authentication. Usually, the mapping is calculated for at least part of the package, and the result of the mapping is included in the package. When the package is received at its destination, the mapping can be checked to detect if some fields in the package have been changed (and thus detect if the package was modified in transit from its origin). In one embodiment, the following mapping functions may have support in the mapping circuit 90: Message Digest 5 (MD-5) / secure mapping algorithm-1 (SHA-1), and authentication authentication mapping code message (HMAC). Other embodiments may implement the SHA-2. Other embodiments may implement any other set of mapping functions, including subsets or supersets of the above functions and other functions.

The encryption circuit 92 can be configured to perform encryption functions. Depending on the secure package specification, the encryption function can be applied to at least a part of the package, possibly including the mapping data. Any set of encryption functions can be supported in various embodiments. For example, in one embodiment, the following encryption / encryption algorithms can be implemented in the encryption circuit 92: data encryption standard (DES), triple data encryption standard (3DES), the advanced encryption standard ( AES), Kasumi, code 4 adduced from Ron (ARC4) and / or code 4 from Ron (RC4).

In some cases, if both authentication and encryption functions are being used, encryption is performed first when preparing a packet for transmission, and then authentication mapping is performed on the encrypted data (for example, IPSec ). In other cases, authentication mapping is carried out first, and packet encryption (including mapping data) is carried out second (for example, SLL). In any case, authentication mapping and encryption is carried out in the opposite order on a received package.

The security circuits 84A-84D can support any order of encryption and data mapping in a single DMA transfer, by connecting the butterfly between circuits 90 and 92. That is, if the encryption is to be carried out first, the data provided to the security circuit 84A can be routed to the encryption circuit 92, and the output of the encryption circuit 92 can be routed to the input of the mapping circuit 90 to calculate the mapping function on encrypted (or encrypted) data. If the mapping is to be carried out first, the data provided to the security circuit 84A can be routed to the mapping circuit 90, and the output of the mapping circuit 90 can be routed to the input of the encryption circuit 92. The security circuits 84A-84D also support the execution of only the mapping or only the encryption function in a given DMA transfer. The control information from the DMA descriptor for DMA transfer directed to the security circuits 84A-84D can control the routing of data through the security circuits 84A-84D.

The illustrated embodiment shows 4 c 84A-84D safety circuits. Other embodiments may include any number of safety circuits, including a safety circuit. In one embodiment, the security circuits 84A-84D can be synchronized at twice the frequency of the system clock used in the system 10 and can receive two operations per system clock cycle (one performed in the first half of the system clock cycle and the other in the second half of the system clock cycle). Thus, there may be 8 logical safety circuits that can be selected by the software to perform security functions.

The CRC generator 86 may be configured to generate CRC data on the data provided in a DMA transfer that specifies CRC generation. CRC generation can also be used to check the CRC data of a received packet. For example, the CRC data generated in the CRC generator 86 can be compared with the corresponding CRC data in the received packet. Alternatively, the CRC data in the received packet can be included in the DMA transfer through the CRC generator 86, and the result can be checked with respect to a predetermined value for errors in the received packet. In some embodiments, there may be more than one CRC generator 86. In addition, the CRC generator, or generators, 86 may (n) be synchronized at twice the system clock frequency, similar to the safety circuits 84A-84D, to provide more logical CRC generators than are provided physically in the discharge engine 44. In a specific embodiment, there may be 4 of the CRC generators 86, synchronized at twice the system clock frequency, to provide an equal number of logic units (8) to the safety circuits 84A-84D.

The checksum generator 88 may be configured to generate a sum of control over the data provided in a DMA transfer that specifies generation of checksums. The generation of checksums can also be used to check the checksum data from a received packet. For example, the checksum data generated in the checksum generator 88 can be compared with the corresponding checksum in the received packet. Alternatively, the checksum data in the received packet can be included in the DMA transfer through the checksum generator 88, and the result can be checked with respect to a predetermined value to detect errors in the received packet. In some embodiments, there may be more than one generator 88 of checksums.

The input buffer 80 may temporarily store data provided by the Tx control circuit 56 until the destination circuit 84A-84D, 86 or 88 can operate on the data. Circuits 84A-84D, 86 and 88 can output data to output buffer 82 to be written to download FIFO 48. In other embodiments, the input buffer 80 and / or the output buffer 82 may not be included.

Fig. 4 is a block diagram illustrating an embodiment of a model for the DMA that can be implemented in an embodiment of the system 10. As mentioned above, a DMA transfer can take place from a space or source address interface (block 100) to a destination address space or interface (block 102). The DMA transfer is represented by block 104 in Fig. 4. Optionally, a DMA transfer may include the execution of one or more operations, or functions (block 106) on the DMA data to produce a result. The result is returned to DMA block 104 and can be provided to the destination address space. In some cases, the result may be transformed DMA data that can be written to the destination address space. In other cases, the result may be different from the DMA data and may increase the DMA data (for example, be added at the end of the DMA data) or it may be stored in a different location (for example, in the descriptor of DMA for DMA transfer).

Fig. 4 may illustrate an individual DMA transfer, in some cases. In other cases, multiple DMA transfers can be used to complete the model of Fig. 4. For example, functions 106 may be carried out by the test loop circuit 40 (or components thereof) for the embodiment of Fig. 2). Thus, in the illustrated embodiment, if it is desired that a function be carried out on a DMA transfer having an interface circuit 16 as destination, two DMA transfers can be carried out. A first DMA transfer, perhaps from a source address space to a destination address space, that specifies the desired functions to be performed. Then, a second DMA transfer can be performed, using the destination address space of the first DMA transfer as the source and the desired interface circuit as the destination.

For example, a package may be prepared by the software for transmission by one of the MAC 34A-34B, and the package may be stored in memory on host 12. Secure transmission using encryption and / or mapping may be desired, and therefore the software can establish a first DMA transfer from the first memory region to a second memory region on host 12, and the first DMA transfer can specify encryption and / or mapping in the unloading engine 44. The software can also prepare a second DMA transfer from the second memory region to the destination MAC 34A-34B. Similarly, a packet can be received as a DMA in memory in host 12, and the software can establish a DMA transfer through download engine 44 to check the mapping and / or decrypt the packet.

Other embodiments may allow functions to be applied as the data is transmitted to an interface circuit 16. In one embodiment, for example, partial generation of checksums can be supported in IOB 22, to generate the sum of control included in the TCP (Transport Control Protocol) header of TCP packets. When a DMA transfer is specified for such a packet, IOB 22 can accumulate packet data in IOM 24 and can generate the partial sum of control for each line of temporary memory. The final control sum can be generated in the DMA controller 14, using the partial checksums for each line of temporary memory from the IOB 22 and the data on which the partial checksums were not calculated, and the controller 14 of DMA can insert the sum of control calculated in the TCP header. Other embodiments may allow the output of the test loop circuit 40 to be routed directly to the interface circuits 16 as part of the individual DMA transfer in which the functions are performed and the data is transmitted. In addition, other embodiments may allow DMA Rx data path data to enter the test loop circuit 40 to perform functions on the DMA data received during the transfer of receiving DMA.

Turning next to Fig. 5, a block diagram of a memory region 110 that stores descriptor data structures and buffer pointer data structures is shown. In the embodiment of Fig. 5, the descriptor data structures include a set of descriptor rings 112A-112N. There may be a descriptor ring for each DMA channel with support from the DMA controller 14 (for example, channel 0 to channel N in Fig. 5). That is, there may be a one-to-one correspondence between the DMA channels and the descriptor rings, and DMA transfers for a given DMA channel may have corresponding descriptors in the descriptor ring 112A-112N assigned to that channel. Additionally, in the embodiment of Fig. 5, the data structures of intermediate memory pointers may include a set of 114A-114M rings of intermediate memory pointers. There may be a ring of intermediate memory pointers per interface circuit 16 (for example, 0 to M interface circuits in Fig. 5, where M + 1 may be the number of interface circuits 16). That is, there may be a one-to-one correspondence between interface circuits and descriptor rings, and the intermediate memory pointers used for the DMAs received by that interface can be taken from the 114A-114M ring of intermediate memory pointers assigned to that circuit. Interface.

Each descriptor ring 112A-112N may comprise a set of descriptors for the corresponding DMA channel. For transmission DMA channels, the descriptors can be processed in the order included within the ring, from the first descriptor in the ring to the last, and then circularly retake the first descriptor in the ring after the last descriptor has been processed. Thus, at a given moment, any descriptor in the ring can be seen as the “current descriptor”, that is, the next one to be processed. The software can control the number of descriptors that are available for processing through the DMA channel in a variety of ways, as mentioned above. Accordingly, if descriptors are available on a given transmission DMA channel (in the corresponding descriptor ring), the DMA controller 14 can carry out the specified DMA transfers (arbitrating the resources with other DMA channels). For the receiving DMA channels in the present embodiment, the descriptors in the corresponding descriptor ring can be consumed as the DMA transfers are received through that channel. The DMA controller 14 may write in the current descriptor the pointer, or pointers, of buffer used to store the received DMA data, as well as other information regarding the DMA transfer, such as the status information of transfer.

Other embodiments may use other data structures (eg, linked lists of descriptors). The base address of each descriptor ring 112A-112N can be provided to the DMA controller 14 (for example, programmed in the configuration records 38D or 38F, depending on whether the channel is a transmission or reception channel). Other attributes of the descriptor ring 112A-112N (for example, the extension) can also be programmed. In some embodiments, the descriptors in a given ring may be of a fixed size, such that a given descriptor may be in a fixed displacement from the base direction of the ring. In other embodiments, the descriptors can be of variable size. In other additional embodiments, the descriptors can be of fixed size or of variable size, according to a programmable attribute in the 38D or 38F configuration registers. The attribute can be programmable channel by channel, or it can be programmed for the channels as a whole.

Each ring 114A-114M of intermediate memory pointers comprises intermediate memory pointers that point to intermediate memory in memory allocated by the software for use in order to store DMA data from DMA Rx transfers from the corresponding interface. Similar to the descriptor rings 112A-112N, the software can make the intermediate memory pointers in the 114A-114M rings of intermediate memory pointers available to the DMA controller 14 in any desired manner. The base address of the buffer ring of pockets for each interface can be programmed in the DMA controller 14 (for example, in the configuration registers 38E in the Rx precapture motor 60, in the embodiment of Fig. 2) and, at any time, one of the intermediate memory pointers in the intermediate memory pointers ring may be the next to be consumed for the corresponding interface.

By providing the 114A-114M rings of intermediate memory pointers associated with the interface circuits, instead of the DMA channels, the software can allocate intermediate memories to the smallest number of interface circuits, rather than to the largest number of DMA channels , in some embodiments. The allocation of memory, in some cases, may be more efficient. Interface circuits that are managing more traffic can be allocated more buffers, without the software having prior knowledge of why channels will receive that traffic. As DMA data is received from a given interface, the data can be stored in the buffers allocated to that interface and the buffer pointers can be written to the descriptor for the channel through which the DMA data is received. The descriptor may be in one of the descriptor rings 112A-112N, depending on which DMA channel is associated with the DMA transfer.

The 114A-114M rings of intermediate memory pointers can also include a size field (Sz in Fig. 5) for each intermediate memory pointer. The size field can indicate the size of the buffer that the corresponding buffer pointer points to. Consequently, the software can allocate buffers of different sizes on the basis, e.g. eg, to the amount of available memory, the expected size of DMA transfers over a given interface, etc.

Turning now to Fig. 6, a flow chart is shown illustrating the operation of an embodiment of the Rx precapture motor 60 for a given interface circuit. The Rx precapture motor 60 may include circuits that implement the operation shown in Fig. 6 for each interface circuit, operating in parallel and independently. While the blocks are shown in a specific order in Fig. 6, to facilitate understanding, the blocks can be implemented in parallel in a combinatorial logic circuit system that implements the operation shown in Fig. 6. In some embodiments, one or more of the blocks, or the total flow chart , can be sequenced over multiple clock cycles.

The Rx precapture engine 60 can determine if intermediate memory pointers are available for the interface circuit (in the 114A-114M ring of intermediate memory pointers corresponding to the interface circuit) (decision block 120) and if pointers are needed. buffer memory for the interface circuit (decision block 122). If at least one buffer memory pointer is available and necessary (decision blocks 120 and 122, “yes” branch), the Rx precapture engine 60 can generate a precapture request to read the buffer pointer, or pointers, of buffer memory of ring 114A-114M of intermediate memory pointers in host memory 12 (block 124).

Buffers may generally be "available" if there are buffers in the corresponding ring 114A-114M of buffers that have not been pre-captured by the Rx precapture engine 60. The buffer pointers may be inserted into the 114A-114M ring of buffer pointers by the software, and the software may indicate that they are available in any of the aforementioned ways (for example, using validation bits in the inputs of the intermediate memory pointer ring, increasing an intermediate memory pointer ring counter, similar to the DMA descriptor counter described above, etc.). Buffers can also be seen as "necessary" in a variety of ways. For example, if a receiving DMA channel is enabled and there are no intermediate memory pointers pre-adapted for the channel, an intermediate memory pointer may be "necessary." In some embodiments, the Rx precapture engine 60 may be programmable to indicate a certain number of intermediate pointers that should be pre-cleaned, or a minimum and maximum number of intermediate memory pointers that should be pre-cleaned. The Rx pre-capture engine 60 can generate pre-capture requests for buffer pointers, in order to attempt to pre-scan the programmed number of buffer pointers.

As mentioned above, the operation of Fig. 6 can be carried out in parallel for each interface circuit enabled. If more than one precapture request is generated concurrently, the Rx precapture motor 60 may also include circuit system to select from the precapture requests. For example, in one embodiment, the Rx precapture engine 60 can implement a fixed priority scheme among the pre-capture requests. In other embodiments, the Rx precapture engine 60 may select the precapture request corresponding to an interface circuit for which the minimum intermediate memory pointers are currently pre-cleaned and ready. As another example, the Rx precapture engine 60 can weigh requests based on which interface circuit has the greatest difference between the number of currently pre-cleaned buffer pointers and the desired number of buffer pointers, for that interface circuit. . Selection mechanisms based on the circular batch or priority may also be used, and these mechanisms may include programmable weighting between the interface circuits, if desired. Starvation prevention mechanisms, such as interface timings, can also be used to ensure pointers are pre-captured for each interface circuit.

The Rx precapture engine 60 can be informed by the IOM / IOB interface circuit 70 when pre-stipulated buffer pointers are available on the IOM 24. The Rx precapture engine 60, in some embodiments, can read some of, or all, the pointers of the IOM 24 in the buffers 64 and can provide the prebuilt buffer pointers to the Rx control circuit 58, as necessary.

Turning now to Fig. 7, a flow chart illustrating the operation of an embodiment of the Rx control circuit 58 in response to data reception is shown. The data can be received either from the test loop circuit 40 or from an interface circuit 16. While the blocks are shown in a specific order in Fig. 7, to facilitate understanding, the blocks can be implemented in parallel in a combinatorial logic circuit system that implements the operation shown in Fig. 7. In some embodiments, one or more of the blocks, or the flow chart in their all, can be sequenced on multiple clock cycles.

The control circuit 58 Rx can determine if a buffer is already in use to receive the DMA data (decision block 130). A buffer may be in use if it has been previously selected to store DMA data and is not yet full. The Rx control circuit 58 may be configured to maintain active buffers for each DMA Rx channel and one or more intermediate memory pointers for the test loop circuit 40. Alternatively, the test loop circuit 40 may provide the intermediate memory pointer with each data transfer, and the Rx control circuit 58 may not maintain the pointers for the test loop circuit 40. If a buffer is not in use (decision block 130, branch "no"), the control circuit Rx may select the next buffer pointer to identify the buffer to be used (block 132). For DMA transfers from the test loop circuit 40, the next intermediate memory pointer is provided by the test loop circuit 40. For DMA transfers from the interface circuits 16, the next buffer pointer may be provided from the Rx precapture engine 60 and the Rx control circuit 58 may indicate the consumption of the pointer to the Rx precapture engine 60.

In any case, the control circuit 58 Rx can write the data received in the buffer memory (block 134). That is, the Rx control circuit 58 can generate a write request to the IOM / IOB interface circuit 70 to write the DMA data into memory. The control circuit 58 Rx can monitor the number of octets written in the buffer to determine when the buffer is full, at least for the data received from the interface circuits 16. In some embodiments, the size of the buffer can be provided by the test loop circuit 40 and the control circuit Rx can also monitor fullness of buffer for test loop transfers. If the buffer is full, or if the data transfer is indicated by the origin (the test loop circuit 40 or the interface circuit 16) as the end of the DMA transfer (decision block 136, branch "yes ”), The Rx control circuit 58 may write the buffer pointer in the descriptor for DMA transfer (block 138). For test loop transfers, there may not be a DMA descriptor for the received data, since the buffer pointers may be destination buffer pointers from the source DMA descriptor, and block 138 may not be executed for such transfers. If the data transfer is indicated as the end of the DMA transfer (decision block 140, "yes" branch), the control circuit Rx can carry out various transfer end processing (block 142). For example, for a DMA transfer from the interface circuits 16, the control circuit 58 Rx can generate various states for the DMA transfer, generate the DMA descriptor header for the transfer, and write the DMA descriptor in the descriptor ring 112A-112N corresponding to the DMA Rx channel through which the data was received. Additionally, the Rx control circuit 58 can signal the end of the transfer to the IOM / IOB circuit 70. The signaling of the end of the transfer can inform the IOM / IOB circuit 70 that no more data will be supplied by that channel. If an incomplete line of temporary memory is updated by the DMA, the IOM / IOB circuit 70 may cause the updated data to be sent to the memory (for example, in IOC 26, in some embodiments, to avoid a cycle read-modify-write through interconnection 30).

Turning then to Fig. 8, a flow chart illustrating the operation of an embodiment of the control circuit 56 Tx for a given DMA channel Tx is shown. The Tx control circuit 56 may include circuits that implement the operation shown in Fig. 8 for each DMA channel Tx, operating in parallel and independently. While the blocks are shown in a specific order in Fig. 8 to facilitate understanding, the blocks can be implemented in parallel in a combinatorial logic circuit system that implements the operation shown in Fig. 8. In some embodiments, one or more of the blocks, or the entire flow chart, They can be sequenced over multiple clock cycles.

The control circuit 56 Tx can determine if descriptors for the channel are available for pre-capture (in the descriptor ring 112A-112N corresponding to the channel) (decision block 150) and if descriptors are needed for the channel (decision block 152). If at least one descriptor is available and necessary (decision blocks 150 and 152, branch "yes"), the Tx control circuit 56 may generate a request to read the descriptors from the descriptor ring 112A-112N in the host memory 12 (block 154).

Similar to the buffer pointers being "available," as described above with respect to Fig. 6, the descriptors may generally be "available" if there are descriptors in the corresponding descriptor ring 112A-112N that have not been pre-captured by control circuit 56 Tx. The descriptors for a DMA Tx channel may be inserted into the descriptor ring 112A-112N by the software, and the software may indicate that they are available in any of the aforementioned ways (for example, using validation bits at the ring inputs descriptor, increasing a descriptor ring counter, etc.). Descriptors can also be seen as "necessary" in a variety of ways. For example, if a DMA Tx channel is enabled and there are no pre-captured descriptors for the channel, a descriptor may be "necessary." In some embodiments, the Tx control circuit 56 may pre-capture descriptors while there is room in IOM 24 and / or in buffers 62 to store the descriptors. In other embodiments, the Tx control circuit 56 may be programmable to indicate a certain number of descriptors that should be pre-cleaned, or a minimum and maximum number of descriptors that should be pre-cleaned. The control circuit 56 Tx can generate pre-capture requests for descriptors, in order to try to pre-capture the programmed number of descriptors.

The Tx control circuit 56 may be informed by the IOM / IOB interface circuit 70 when available, for reading, descriptors pre-captured in the IOM 24. The Tx control circuit 56, in some embodiments, may read some of, or all, the descriptors from IOM 24 in buffers 62.

The control circuit 56 Tx can determine if DMA data is available for pre-capture for the channel (to be transmitted on the channel) (decision block 156) and if DMA data is needed for the channel (decision block 158). If the DMA data is available and necessary (decision blocks 156 and 158, "yes" branch), the Tx control circuit 56 may generate a request to read the DMA data from the address space of the host 12 (for example , from memory locations on host 12) (block 160).

DMA data can be considered as available for pre-capture if control circuit Tx 56 has a descriptor to be processed (for example, the descriptor is the next to be processed from the descriptor ring for the channel), the descriptor data is in Buffers 62 or IOM 24, and descriptor data describe a valid DMA transfer to be carried out. DMA data may be necessary if previous DMA data has been transmitted through the channel (or will be transmitted soon). In some embodiments, the Tx control circuit 56 may be programmable as to how much DMA data is to be pre-captured at any given time, and DMA data may be necessary if it has been pre-captured, and not yet transmitted, less than Desired amount of DMA data. In some embodiments, the arbitration scheme between transmission channels may also affect whether DMA data is necessary (for example, if the channel does not win arbitration for a relatively large period of time, DMA data may not still necessary, since they cannot be transmitted until the arbitration wins).

It is noted that the operation illustrated by blocks 156, 158 and 160 may be independent of the operation of blocks 150, 152 and 154 (except that the pre-captured descriptors are used to determine if DMA data is available). Consequently, the circuit system that implements blocks 156, 158 and 160 can be independent of the circuit system that implements blocks 150, 152 and 154, and can evaluate in parallel with such a circuit system.

As mentioned above, the operation of Fig. 8 can be carried out in parallel for each DMA Tx enabled channel. If more than one precapture request is generated concurrently, the Tx control circuit 56 may also include circuits to select from the precapture requests. For example, the control circuit 56 Tx can select the pre-capture request corresponding to the DMA channel Tx for which the minimum descriptors or the minimum amount of DMA data are currently pre-prepared and ready. As another example, the Tx control circuit 56 can weigh requests based on which DMA channel Tx has the greatest difference between the descriptors, or DMA data, currently preset and the desired number of descriptors, or amount of DMA data. , for that channel. Selection mechanisms may also be used based on the circular batch or priority, and these schemes may include programmable weighting between the channels, if desired. Starvation prevention mechanisms, such as timer expirations per channel, can also be used to ensure that DMA descriptors and data are pre-captured for each enabled channel.

The Tx control circuit 56 may be informed by the IOM / IOB interface circuit 70 when the pre-captured DMA data in IOM 24 is available for reading. The Tx control circuit 56, in some embodiments, you can read some or all of the DMA data of IOM 24 in buffers 62. Additionally, the Tx control circuit 56 can transmit the pre-purified DMA data to the destination, as illustrated for an embodiment in Fig. 9. While the blocks are shown in a specific order in Fig. 9, to facilitate understanding, the blocks can be implemented in parallel in a combinatorial logic circuit system that implements the operation shown in Fig. 9. In some embodiments, one or more of the blocks, or the entire flowchart, can be sequenced over multiple clock cycles.

If the DMA channel Tx is assigned to the test loop circuit 40 (or, more specifically, to a test loop component in the test loop circuit 40 - decision block 162, branch "yes"), the circuit Control 56 Tx can extract the pointer, or pointers, of destination buffer from the DMA descriptor for transfer, and for transmitting with the DMA data (block 164). The size information for each destination buffer pointer can also be provided such that the control circuit Rx 58 can be informed of the size of the buffers. The test loop circuit 40 may receive the pointer, or pointers, of the destination buffer and provide it (s) with the data to be written in memory (either the original DMA data, e.g., in a copy transfer of DMA, or the transformed DMA data, e.g. eg, if encryption is performed). Alternatively, a pointer to the DMA descriptor can be provided if the test loop result is to be written to the DMA descriptor (for example, a mapping result, a CRC result or a checksum result). The control circuit 56 Tx can transmit the data to the destination interface circuit 16 or to the test loop component (block 166) together with the channel number, pointers (if any) and control information (if the there would be). The control information can also be extracted from the DMA descriptor (for example, selection information of the desired test loop operation (s), control information for the interface circuits, etc.).

The operation of Fig. 9 can be carried out in parallel for each DMA channel Tx. That is, control circuit 56 Tx may include independent circuits that implement the operation of Fig. 9 in parallel for each DMA channel Tx. An arbitration mechanism can be used to arbitrate between channels that have DMA data to transmit, and to select a channel that transmits through the transmission data path to the interface circuits 16 and the test loop circuit 40.

The descriptor rings 112A-112N have been previously described as stores of various descriptors. In one embodiment, the descriptor rings 112A-112N can store both transfer descriptors (which describe a transfer of DMA from a source to a destination) and control descriptors. Control descriptors cannot specify a DMA transfer but instead can encode control information for the channel. For example, control descriptors can be used to specify the configuration (for example, the content of one or more configuration records 38A-38G). Thus, the control descriptors can be used to reconfigure the DMA controller 14, the components thereof or other components of the system 10 on the fly, between DMA transfers. Accordingly, the software may, for example, establish one or more transfer descriptors to perform DMA transfers with a first configuration, establish one or more control descriptors to change the configuration, establish one or more additional transfer descriptors for carry out DMA transfers with a second configuration and then make the descriptors available through the DMA channel as a unit. DMA transfers, reconfiguration and additional DMA transfers can be carried out without processor intervention.

Other types of control descriptors are also contemplated, which control the DMA controller 14 without explicitly causing a DMA transfer. For example, a temporary trigger descriptor is contemplated that causes a temporary delay through the DMA channel when the temporary trigger descriptor is processed. For example, the system 10 may include a timer that can be programmed with a delay value, and the processing of the next descriptor in the descriptor ring may be delayed until the timer expires. The expiration of the timer can generate an activation event for the DMA controller 14, to "wake up" the DMA controller 14. The user can program the timer with the delay value, or the delay value can be included in the temporary trigger descriptor, in various embodiments. In other embodiments, the DMA controller 14 may implement the timer. The temporary activator descriptor can have a wide variety of uses. For example, temporary trigger descriptors can be interspersed with DMA copy descriptors that copy from a source address space to a destination address space. The source address space may comprise one or more memory mapped I / O records, or other system status records. Thus, repeated DMA copy transfers can be used to read the records and write the results to the destinations, delayed by the temporary trigger descriptor. DMA copy transfers can take the place of a software polling loop in processors 18A-18B, freeing up the processors for other operations.

Fig. 10 is a block diagram of an embodiment of the descriptor ring 112A corresponding to channel 0, illustrating an example of inserting a control descriptor into the transfer descriptors in a descriptor ring. More than one control descriptor may be inserted in the manner of Fig. 10 (either consecutively or at different points in the ring), as desired.

In Fig. 10, 2 transfer descriptors 170A-170B are shown, followed by a control descriptor 172, followed by 2 more transfer descriptors 170C-170D. Thus, for this example, the two DMA transfers specified by the descriptors 170A-170B would be carried out by the control circuit 56 Tx, followed by the processing of the control descriptor 172. Following the processing of control descriptor 172, the two DMA transfers specified by descriptors 170C-170D would be carried out.

Fig. 11 is a flow chart illustrating the further processing that an embodiment of the control circuit Tx 56 may employ for control descriptors inserted with transfer descriptors in a descriptor ring corresponding to a DMA channel Tx. The Tx control circuit 56 may include circuit system that implements the operation shown in Fig. 11 for each DMA channel Tx, operating in parallel and independently. Although the blocks are shown in a specific order in Fig. 11, to facilitate understanding, the blocks can be implemented in parallel in a combinatorial logic circuit system that implements the operation shown in Fig. 11. In some embodiments, One or more of the blocks, or the entire flowchart, can be sequenced over multiple clock cycles.

The control circuit 56 Tx can preset a descriptor from the descriptor ring (block 174), assuming that one is available and necessary for the channel (for example, as described with respect to Fig. 8). The control circuit 56 Tx can process the descriptor when it is returned to the control circuit 56 Tx, and can determine if the descriptor is a control descriptor (decision block 176). For example, the descriptor header may include a type field that specifies whether the descriptor is a transfer descriptor or a control descriptor. If the descriptor is a transfer descriptor (decision block 176, "no" branch), control circuit 56 Tx can process the transfer descriptor (block 177). For example, the processing of the transfer descriptor may be similar to the description above with respect to Figs. 8 and 9.

If the descriptor is a control descriptor (decision block 176, branch "yes"), the control circuit Tx can determine whether the control descriptor is a temporary trigger descriptor (decision block 178). A temporary trigger descriptor can be indicated by an encoding in the header of the control descriptor. Alternatively, a temporary trigger descriptor can specify a value to be loaded into a configuration register 38A-38G, similar to other configuration descriptors. The loaded value can specify the desired delay. The Tx control circuit 56 can detect the temporary trigger by decoding the registration address of the loaded configuration register. If the control descriptor is a temporary trigger descriptor (decision block 178, branch "yes"), control circuit 56 Tx can delay processing of the next descriptor from the descriptor ring until the delay specified by the descriptor of temporary trigger (block 180). If the control descriptor is not a temporary trigger descriptor (decision block 178, branch "no"), the control circuit Tx 56 can be reconfigured using the values ​​of the control descriptor (block 182). For example, the control descriptor may comprise a register address that identifies a configuration register 38A-38G and a value to be written to the configuration register. The control circuit 56 Tx can cause the writing to take place. Alternatively, the control descriptor may include a buffer pointer to a memory buffer that stores a list of register addresses and values ​​to be written to those registers. Thus, a relatively large number of configurations can be carried out using a control descriptor. The instructions for writing to each configuration register, executed on processors 18A-18B, can be eliminated using a control descriptor, in some embodiments.

Figs. 12-16 illustrate examples of descriptors of various types according to an embodiment of the DMA controller 14. Generally, the descriptors comprise a header, optionally a data field for storing a result (for example, a result generated by the test loop circuit 40) and one or more intermediate memory pointers that point to buffers that store data from DMA (source buffer pointers) or buffers that can be used to store DMA data (destination buffer pointers).

In the present embodiment, the descriptors vary based on whether they are receiving or transmitting DMA, or the function to be performed by the test loop circuit 40, if selected. Reception descriptors are used for DMA Rx transfers, and other types of descriptors are used for DMA Tx transfers and test loop functions. The DMA controller 14 (and more specifically the control circuit 56 Tx, in one embodiment) can determine the format of the descriptors in a descriptor ring for a given DMA channel Tx, based on the assignment of that channel to the interface circuits 16 or a function in the test loop circuit 40.

In Figs. 12-16, various fields are illustrated in detail (for example, the particular header field). Although certain information is shown in Figs. 12-16, it is not intended to exclude the use of other information in addition to that illustrated,

or in addition to a subset of the illustrated one, or as an alternative to the illustrated one. Various additional information may be included, in various implementations, as desired.

Fig. 12 is a block diagram of an embodiment of a receiving descriptor 190. The receiving descriptor 190 may be in the format of the descriptors generated by the control circuit 58 Rx and be written in the descriptor rings 112A-112N corresponding to DMA channels Rx. In the embodiment of Fig. 12, the reception descriptor 190 includes a header field 192 (illustrated in expanded view in Fig. 12 for one embodiment), an optional field 194 of mapping result, and one or more fields 196A-196N of intermediate memory pointers. Each buffer 196A-196N field of buffer pointer includes a size field that can be encoded with the size of the buffer, and a pointer field encoded with the pointer to the buffer. The Rx control circuit 58 can be configured to write, in the fields 196A-196N of intermediate memory pointers, the used memory pointers, coming from the 114A-114M rings of intermediate memory pointers, to store the received DMA data . The mapping result field 194 can be used to store a mapping result.

The expanded view of the receiving header field 196 includes a type 192A field, a style 192B field, a mapping reserve field 192C, a buffer memory field 192D, a packet length 192E field and a field 192F status. Type field 192A can encode the type of descriptor, e.g. eg, control descriptor or transfer descriptor. Type field 192A (and other similar type fields described below for other descriptors) can identify the descriptor as a transfer descriptor, except for the control descriptor shown in Fig. 16. The style field 192B can encode the descriptor style, which refers to whether the buffer pointers in fields 196A-196N of buffer pointers include both source and destination pointers, or only destination pointers (since the origin is an interface circuit for DMA Rx transfers). The mapping reservation field 192C can be used to indicate whether or not the optional mapping result field 194 is included in the descriptor. The buffer memory field 192D can be encoded with a counter of the number of buffers used to store the received DMA data and, therefore, the number of fields 196A196N of buffer pointers. The 192E packet length field can be encoded with the length of the packet stored in the buffers (for example, in octets). The status field 122F may comprise various states of the transfer, which may include the state generated by the control circuit 58 Rx (eg error indications) and / or the state provided by the source interface circuit 16. The control circuit 58 Rx can write the receive header 192 at the end of a DMA transfer.

Fig. 13 is a block diagram of an embodiment of a transmission descriptor 200. The transmission descriptor 200 may be in the format of the descriptors used by the Tx control circuit 56 for transfers from DMA Tx to interface circuits 16, in particular, to the MAC 34A-34B, and may be written by the software in the 112A-112N descriptor rings corresponding to DMA Tx channels assigned to the interface circuits 16. In the embodiment of Fig. 13, the transmission descriptor 200 includes a header field 202 (illustrated in expanded view in Fig. 13 for an embodiment) and one or more fields 204A-204N of buffer pointers. Each buffer memory 204A-204N field includes a size field that can be encoded with the size of the buffer, and a pointer field encoded with the buffer to the buffer. The control circuit 56 Tx can be configured to read fields 204A-204N of buffer pointers, in order to pre-capture the DMA data of the buffers, for transmission.

The expanded view of the transmission header field 202 includes a type field 202A, a style field 202B, a MAC configuration field 202C, a packet length field 202D and a packet information field 202E. Type field 202A and style field 202B may be similar to type field 192A and style field 192B described above. The MAC configuration field 202C can be encoded with various MAC configuration information specific to the packet for the MAC 34A-34B which is the destination of the DMA transfer. For example, the MAC configuration field 202C may include the local area virtual network (VLAN) configuration (for example, nothing, insert, delete or modify), the CRC configuration (for example, nothing, insert CRC, fill in CRC, modify CRC) and if the MAC source address is modified or not. The packet length field 202D can be encoded with the length of the packet stored in the buffers (for example, in octets). Field 202E of packet information can be encoded with various information describing the packet (eg, IP header length, Ethernet header length, packet type (TCP / UDP), checksum enablement, etc.) .

Fig. 14 is a block diagram of an embodiment of a copy descriptor 210. The copy descriptor 210 may be in the format of the descriptors used by the Tx control circuit 56 for DMA copy transfers (from one memory region on host 12 to another memory region on host 12) using FIFO 42 copy. Thus, the copy descriptor 210 can be used in the descriptor rings 112A-112N corresponding to the DMA channels Tx assigned to the copy FIFO 42. In the embodiment of Fig. 14, the copy descriptor 210 includes a header field 212 (illustrated in expanded view in Fig. 14 for an embodiment) and one or more fields 214A-214N of memory pointers intermediate. Each buffer memory 214A-214N field includes a size field that can be encoded with the size of the buffer, and a pointer field encoded with the pointer to the buffer. Additionally, in this embodiment, each intermediate memory pointer field 214A-214N includes an origin / destination (S / D) field that identifies the pointer as well as an origin pointer (which locates an intermediate memory that stores data from Source DMA) or as a destination pointer (which locates a buffer in which DMA data is to be stored). The Tx control circuit 56 may be configured to read the fields 214A-214N of buffer pointers in order to pre-capture the DMA data from the source buffers for transmission, and to provide the destination pointers to the FIFO 42 of copy for transmission to the Rx control circuit 58.

In one embodiment, there may be more than one source pointer for a destination pointer given in the copy descriptor 210. The DMA controller 14 may copy data from the source buffers, in the order listed in the copy descriptor 210, to the destination buffer. Thus, the DMA controller 14 can support the collection of scattered data from multiple memory regions to a destination memory region in the copy operation. Similarly, in one embodiment, there may be more than one destination pointer for a source pointer given in the copy descriptor 210. In such embodiments, the dispersion of data from the source buffer may be supported.

The expanded view of the transmission header field 212 includes a type field 212A, a style field 212B, a source type field 212C, a destination type 212D field and a logical block length 212E field. Type field 212A and style field 212B may be similar to type field 192A and style field 192B described above. The source type field 212C and the destination type field 212D can be coded to indicate how the pointer, or pointers, of the source buffer and the pointer, or pointers, of the destination buffer should be modified as the transfer of Dma. For example, each buffer pointer can be of one of the following types, in one embodiment: sequential increment; sequential decrement; or fixed (with various fixed widths, p. e.g. 1, 2, 4, 8 or 16 octets). The sequential increase indicates that the address increases after each data transmission in the amount of data transmitted. The sequential decrement is similar, but the address is decremented. Sequential increment or sequential decrement can be used for memory regions where data is written to sequential memory locations. The fixed option can be used if an address is mapped by memory to a register or port of a device, and the width can be the width of each transmission to the register / device. The source type field 212C can also have an encoding for zero, and can be used to write a block of zeros at the destination. The destination type field 212D may also have an encoding for capture only, in which the source DMA data is pre-captured, but not written to a destination. The logical block length field can be used, in some embodiments, to indicate the length of a logical DMA block that can span multiple DMA descriptors. That is, the logical DMA operation can be specified effectively using multiple descriptors, and the length of the logical DMA block can be the length of the logical DMA operation (for example, the total sum of the data transfer over the multiple descriptors) .

The XOR circuit 46 may use descriptors that are similar to the transmission DMA descriptor 200. Multiple channels can be assigned to the XOR 46 circuit, and the descriptors in each of the channels can specify one of the XOR sources. The first channel can also specify the destination for the result of the XOR (a memory or destination buffers).

Fig. 15 is a block diagram of an embodiment of a download descriptor 220. The download descriptor 220 may be in the format of the descriptors used by the Tx control circuit 56 for DMA transfers that specify the download engine 44. Thus, the discharge descriptor 220 can be used in the descriptor rings 112A-112N corresponding to DMA channels Tx assigned to the discharge motor 44. In the embodiment of Fig. 15, the download descriptor 220 includes a header field 222 (illustrated in expanded view in Fig. 15 for one embodiment), an optional result reserve field 224 and one or more memory pointer fields 226A-226N intermediate. Each buffer 226A-226N field includes a size field that can be encoded with the size of the buffer and a pointer field encoded with the pointer to the buffer. Additionally, in this embodiment, each intermediate memory pointer field 226A-226N includes an origin / destination (S / D) field that identifies the pointer as well as an origin pointer (which locates an intermediate memory that stores data from Source DMA) or as a destination pointer (which locates a buffer in which DMA data is to be stored). The control circuit 56 Tx can be configured to read the fields 226A-226N of buffer pointers in order to pre-capture the DMA data from the source buffers and to identify destination buffers, if any. If the transformed DMA data is the result of the download engine 44, there may be destination pointers for the transformed DMA data. If a result other than DMA data is generated (for example, for storage in result reserve field 224), there may be no destination pointer in some cases and DMA data may not be written to a destination.

The expanded view of the download header field 222 includes a type field 222A, a style field 222B, a result reserve field 222C, an encryption mode field 222D, a function number field 222E, a 222F field of logical block length and a 222G field of download control. The type field 222A and the style field 222B may be similar to the type field 192A and the style field 192B described above, and the logical block length field 222F may be similar to the logical block length 212E field described above. . The result reserve field 222C may be encoded to indicate whether or not the result reserve field 224 is included in the download header descriptor 220, and may also indicate the size of the result reserve field 224 (e.g., 64 bits, 192 bits or 320 bits, in one embodiment). The result reserve field 224 can be used to store the result generated by the download engine 44, if the result is not transformed DMA data or is generated in addition to the transformed DMA data. The encryption mode field 222D can be encoded with the desired mode for the download engine 44 to process the data, if any. The encryption mode may include: nothing, only signature (for example, CRC or checksum in generators 86 or 88), only encryption, only encryption, encryption and mapping (with options to map first or encrypt first), or encryption and mapping (with options to map first or decrypt first). The function number field 222E can be encoded with the function number for those modalities that use the security circuits 84A-84D (for example, one among eight logical functions formed from the security circuits 84A-84D, as mentioned previously). The 222G download control field may include additional control information for DMA transfer. For example, the length of each one between the signature header, the encryption header, the encryption epilogue and the mapping size can be included in the download control field 222G. Similarly, the selected encryption / encryption (encryption) algorithm, the mapping algorithm and the block encryption mode can be encoded in the download control field 222G. Various other control bits may also be included in the download control field 222G.

Fig. 16 is a block diagram of an embodiment of a control descriptor 230. The control descriptor 230 may be in the format of the control descriptors used by the control circuit 56 Tx on any DMA channel. In the embodiment of Fig. 16, the control descriptor 230 includes a header field 232 (illustrated in expanded view in Fig. 16 for an embodiment) and a data or size / pointer field 234. The data or size / pointer field 234 can either store online data to be written to a configuration record 38A-38G or a buffer buffer (and buffer size) that points to a buffer that stores a list of registration addresses and configuration data to be written to the records.

The expanded view of the control header field 232 includes a type 232A field, an inline / pointer indication field 232B, an interface / function Identifier field 232C, and a registration address field 232D. Type field 232A may be similar to type field 192A described above, which identifies descriptor 230 as a control descriptor. The online indication / pointer field 232B can be encoded to indicate whether the data or size / pointer field 234 stores online data to be written to a configuration register, a pointer to a buffer of registration addresses and data of configuration, or an event. The Interface / Function Identifier field 232C is coded to identify the destination of the configuration data (for example, an interface circuit, a function in the download engine 44, etc.). Registration addresses may be local to the Interface / Function Identifier in this embodiment. The registration address field 232D can be encoded with a registration address if the control descriptor 230 has data online.

Turning now to Fig. 17, a block diagram of an embodiment of the control sum generator 88 is shown. In the embodiment of Fig. 17, the control sum generator 88 includes a plurality of 16-bit carry and guard summers (CSA) 3: 2 240A-240G, a full adder 242 and an accumulator (ACC) 244 16 bits. The control sum generator 88 is coupled to receive a 128-bit input (16 octets) (for example, from the control circuit 56 Tx). The 128-bit input is divided into 16-bit parts that are supplied as inputs to the CSA 240A-240C. Additionally, the output of the accumulator 24 is coupled as an input to the CSA 240C. Each CSA 240A-240C issues a sum and a carry term, marked "S" and "C" in Fig. 17. The sum and carry outputs of the CSA 240A-240C are entered in the CSA 240D-240E. The sum and carry outputs of the CSA 240D and the carry output of the CSA 240E are entered into the CSA 240F. The summation output of the CSA 240E and the summation and hauling outputs of the CSA 240F are entered into the CSA 240G. The sum and carry outputs of the CSA 240G are entered in the complete adder 242, which produces the sum to be stored in the accumulator 244.

CSAs receive N-bit inputs and produce sum and carry out terms that do not refloat carry-over from position to position. That is, the output bits of the sum are the sum of the input bits in that bit position, regardless of the bits in the other bit positions. Each addition bit can be the result of the XOR operation of the input bits in that bit position. The carry-out bits are the carry of the sum of a given bit position, regardless of the carry in other bit positions. Arithmetically, the carry term is seen as the carry to be introduced in the next most significant bit position. Consequently, the carry bit in the least significant bit position is zero, and there are logically N + 1 carry bits coming from a CSA of N bits.

As illustrated by arrows 246, at each point where a carry term issued from a CSA is provided as input to another CSA or to the full adder 242, the most significant carry bit is "circularly shifted" to the least significant bit of the term. Hauling That is, the most significant bit of the carry term is deleted from the most significant bit position and inserted into the least significant bit position, instead of the least significant bit, which is always zero. In this way, the inputs to each CSA and the full adder 242 are always 16 bits, and all carry bits are represented in the inputs. For the 16-bit CSAs shown in Fig. 17, the carried carry term can logically be a value of 17 bits with the least significant bit equal to 0. The transmitted carry term is entered into the next CSA (or the complete adder 242) as follows:

Entry [15: 0] = Hauling [15: 1] || Haul [16] (and Haul is discarded [0] = 0)

The circular shift of the most significant carry bit to the least significant carry bit can be achieved through wired routing between the output of the carry term of a CSA and the input to the next CSA.

In some embodiments, the control sum generator 88, as illustrated in Fig. 17, can generate a 16-bit control sum in one step, storing the control sum in the accumulator 244. The accumulator 244 also it can be 16 bits in this embodiment, since the carry has been circularly shifted and added by the CSA 240A-240G and the full adder 242 as each 128 bit input is accumulated in the control sum.

For the generation of checksums a complementary sum is being generated to some. It can be shown that the circular shift of carry bits emitted by CSAs from the most significant bit to the least significant bit generates a correct sum complementary to ones.

The CSA 240A-240G can be seen as a set of CSA levels. The first level of the CSAs (the CSA 240A240C) have inputs coupled with the inputs to the control sum generator and an input coupled with the output of the accumulator. At other levels, the inputs are coupled with the outputs of the CSAs at a previous level (or levels, eg, in the case of the CSA 240G). At each level, the carry-out outputs of the preceding levels have their most significant bits circularly shifted to the least significant bit to enter that level.

The present embodiment can use 16-bit CSAs to produce a 16-bit checksum that is used in TCP, IP and ICMP. Other embodiments may use control sums, major or minor, and greater or lesser CSA may be used in such embodiments. Thus, in general, a 3-bit CSA of N bits can be used. Similarly, while a 128-bit input is used in the illustrated embodiment, other embodiments may use any number of input bits. The number of CSA levels can be changed accordingly.

Although the embodiment of Fig. 17 is shown as implemented in the control sum generator 88, similar circuits can be used in the IOB 22 for the partial generation of control sums (as described above) and in the circuits 16 interface to complete the partial control sum.

Turning now to Fig. 18, a block diagram of an embodiment of the complete adder 242 is shown. In the illustrated embodiment, the complete adder 242 may include an XOR circuit 250 and a pair of circuits 252A-252B of carry generation. The XOR 250 circuit and the 252A-252B carry-generation circuits are coupled to receive inputs "a" and "b" to the complete adder (which are the sum and carry outputs of the CSA 240G in Fig. 17, with the most significant bit of the carry output removed and inserted into the least significant bit). The haul generator 252A is coupled to receive a zero (Centered) haul input, and the haul generator 252B is coupled to receive a haul input of one. The carry output (Output) of the carry generator 252A is provided as the selection control of a multiplexer (mux) 254, which has the carry outputs of the carry generators 252A-252B as inputs. The output of mux 254 is coupled as an input to a second XOR 256 circuit, which also has the output of the XOR 250 circuit as an input. The output of the XOR 256 circuit is the output of the full adder 242.

The XOR 250 circuit performs the bitwise XOR logic operation of the inputs a and b, effectively carrying out another generation of sum term similar to the CSA 240 adders. The haul generators 252A-252B carry out a true haul generation on the inputs a and b, and if the haulage output of the haul generator 252A is zero, the haul generator 252A output is selected through mux 254 for the XOR operation with the sum term from the XOR 250 circuit, thereby creating the final sum complementary to some. On the other hand, if the hauling output of the hauling generator 252A is one, the output of the hauling generator 252B is selected through mux 254. As the hauling input to the hauling generator 252B is a one, the generator 252B Hauling has effectively shifted the haul output circularly from the most significant bit again. Seen in another way, the carry generators 252A-252B and the mux 254 can selectively shift, one more carry bit, based on whether or not the carry is generated.

Aspects of the object described in this document are set out in the following numbered clauses:

1. An apparatus comprising:

a first interface circuit configured to communicate by an interface according to a protocol; a direct memory access controller (DMA) coupled with the first interface circuit; and

a host coupled to the DMA controller, wherein the host comprises at least one address space mapped, at least in part, to a plurality of memory locations in a host memory system;

in which the DMA controller is configured to carry out DMA transfers between the first interface circuit and the address space, and in which the DMA controller is additionally configured to carry out DMA transfers between a first plurality of memory locations and a second plurality of memory locations.

<dl><dt>2. </dt><dd>The apparatus as recited in clause 1, wherein the DMA controller comprises a transmission control circuit, a reception control circuit and a test loop circuit coupled with the transmission control circuit and the control circuit. of reception, in which the transmission control circuit is configured to read data from the first plurality and provide the data to the test loop circuit, and wherein the test loop circuit is configured to provide the data to the reception control circuit, and in which the reception control circuit is configured to write the data in the second plurality. </dd></dl>

<dl><dt>3. </dt><dd>The apparatus as recited in clause 2, in which the reception control circuit is additionally configured to write data of the first interface circuit in the address space, and in which the DMA controller comprises an arbitrator configured to arbitrate between the test loop circuit and the first interface circuit, in order to provide data to the reception control circuit. </dd></dl>

<dl><dt>4. </dt><dd>The apparatus as recited in any of clauses 1 to 3, wherein the first interface circuit comprises a media access controller (MAC). </dd></dl>

<dl><dt>5. </dt><dd>The apparatus as recited in clause 4, further comprising a plurality of interface circuits, including the first interface circuit, in which the plurality of interface circuits are coupled with the DMA controller. </dd></dl>

<dl><dt>6. </dt><dd>The apparatus as recited in any of clauses 1 to 3, wherein the first interface circuit comprises a peripheral interface controller circuit. </dd></dl>

<dl><dt>7. </dt><dd>The apparatus as recited in clause 6, further comprising a plurality of interface circuits that includes the first interface circuit, in which the plurality of interface circuits are coupled with the DMA controller. </dd></dl>

<dl><dt>8. </dt><dd>The apparatus as recited in clauses 6 or 7, wherein a second interface circuit of the plurality of interface circuits comprises a media access controller (MAC). </dd></dl>

<dl><dt>9. </dt><dd>The apparatus as recited in any of clauses 1 to 8, wherein the direct memory access controller (DMA) is configured to carry out a DMA transfer from the address space to a destination, in which the destination it is either the interface circuit or the host, dependent on a channel to which the DMA transfer is assigned, and wherein the DMA controller is configured to perform at least a first operation on the first DMA data read from the address space for DMA transfer, the first operation producing a result. </dd></dl>

<dl><dt>10. </dt><dd>The apparatus as recited in clause 9, wherein the first operation transforms the first DMA data into the second DMA data, and the DMA controller is configured to transfer the second DMA data to the destination. </dd></dl>

<dl><dt>11. </dt><dd>The apparatus as recited in clauses 9 or 10, in which the first operation comprises encryption. </dd></dl>

<dl><dt>12. </dt><dd>The apparatus as recited in clause 11, in which the DMA controller is additionally configured to apply a mapping function to the first DMA data, and in which the result comprises the output of the mapping function. </dd></dl>

<dl><dt>13. </dt><dd>The apparatus as recited in clauses 9 or 10, wherein the result is stored in a data structure of a DMA descriptor corresponding to the first DMA data. </dd></dl>

<dl><dt>14. </dt><dd>The apparatus as recited in clause 13, in which the first operation is a mapping function. </dd></dl>

<dl><dt>15. </dt><dd>The apparatus as recited in clause 13, wherein the first operation is a generation of cyclic redundancy control. </dd></dl>

<dl><dt>16. </dt><dd>The apparatus as recited in clause 13, in which the first operation is a control sum generation. </dd></dl>

<dl><dt>17. </dt><dd>The apparatus as recited in clause 9, wherein the DMA controller is configured to read data from a plurality of channels and to carry out the logical XOR operation on the data in order to produce the result. </dd></dl>

<dl><dt>18. </dt><dd>A procedure comprising: </dd></dl>

a direct memory access controller (DMA) that performs a first DMA transfer between a first interface circuit and an address space on a host, in which the address space is mapped, at least in part, to a plurality of memory locations on the host, in which the first interface circuit is configured to communicate by an interface according to a protocol; and

the DMA controller that performs a second DMA transfer between a first plurality of the plurality of memory locations and a second plurality of the plurality of memory locations.

<dl><dt>19. </dt><dd>The procedure as recited in clause 18, wherein the first interface circuit comprises a media access controller (MAC). </dd></dl>

<dl><dt>20. </dt><dd>The method as recited in clauses 18 or 19, wherein the DMA controller is coupled with a plurality of interface circuits that includes the first interface circuit, in which the plurality of interface circuits are coupled with the controller of DMA </dd></dl>

<dl><dt>21. </dt><dd>The method as recited in any of clauses 18 to 20, wherein a second interface circuit of the plurality of interface circuits comprises a peripheral interface controller circuit. </dd></dl>

<dl><dt>22. </dt><dd>A direct memory access controller (DMA) comprising: </dd></dl>

a transmission control circuit configured to read first DMA data from an address space in a host and to provide the first DMA data either to a download engine in the DMA controller or to an interface circuit, dependent on a channel to which the DMA transfer is assigned; and

the download engine coupled to receive the first DMA data from the transmission control circuits, in which the download engine is configured to carry out at least a first operation on the first DMA data to produce a result, in that the download engine is configured to begin at least performing the first operation during a DMA transfer that provides the first DMA data to the download engine; and

a reception control circuit coupled to the download engine to receive the result, in which the reception control circuit is configured to write the result in the address space in the host according to a data structure of a DMA descriptor which describes the DMA transfer, and in which the reception control circuit is additionally configured to write data received from the interface circuit in the address space.

<dl><dt>23. </dt><dd>The DMA controller as recited in clause 22, in which the first operation transforms the first DMA data into the second DMA data, and in which the discharge motor is coupled to the reception control circuit and is configured to provide the second DMA data to the reception control circuit. </dd></dl>

<dl><dt>24. </dt><dd>The DMA controller as recited in clauses 22 or 23, in which the first operation comprises encryption. </dd></dl>

<dl><dt>25. </dt><dd>The DMA controller as recited in any of clauses 22 to 24, in which the download engine is additionally configured to apply a mapping function to the first DMA data, and in which the result comprises the output of the function of mapping. </dd></dl>

<dl><dt>26. </dt><dd>The DMA controller as recited in any of clauses 22 to 25, wherein the result is stored in a data structure of the DMA descriptor, which corresponds to the first DMA data. </dd></dl>

<dl><dt>27. </dt><dd>The DMA controller as recited in clause 26, in which the first operation is a mapping function. </dd></dl>

<dl><dt>28. </dt><dd>The DMA controller as recited in clause 26, wherein the first operation is a generation of cyclic redundancy control. </dd></dl>

<dl><dt>29. </dt><dd>The DMA controller as recited in clause 26, in which the first operation is a checksum generation. </dd></dl>

<dl><dt>30. </dt><dd>The DMA controller as recited in any of clauses 2.2 to 29, further comprising a </dd></dl>

5 exclusive O circuit (XOR), in which the transmission control circuit is configured to read data from a plurality of channels and provide the data to the XOR circuit, in which the XOR circuit is configured to perform the XOR logic operation on the data in order to produce the result.

31. A direct memory access (DMA) controller configured to read the first DMA data from a

10 address space on a host and provide the first DMA data either to a download engine in the DMA controller or to an interface circuit, dependent on a channel to which the DMA transfer is assigned, in which the engine Download is configured to perform at least a first operation on the first DMA data in order to produce a result, in which the download engine is configured to initiate at least the execution of the first operation during a DMA transfer that provides the first DMA data to the delivery engine.

fifteen download, and in which the DMA controller is configured to write the result in the address space on the host according to a data structure of a DMA descriptor describing the DMA transfer, and in which the DMA controller is additionally configured to write data received from the interface circuit in the address space.

twenty Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be construed as encompassing all such variations and modifications.