Copending, commonly-assigned U.S. patent application Ser. Nos. 10/351,030 and 11/127,445, filed on Jan. 24, 2003 and May 11, 2005, respectively, are incorporated herein by reference.
This invention relates generally to memory interfaces, and more specifically to determining checksums during direct memory access (DMA) operations.
In the data communications field, a packet is a finite-length (generally several tens to several thousands of octets) digital transmission unit comprising one or more header fields and a data field. The data field may contain virtually any type of digital data. The header fields convey information (in different formats depending on the type of header and options) related to delivery and interpretation of the packet contents. This information may, e.g., identify the packet's source or destination, identify the protocol to be used to interpret the packet, identify the packet's place in a sequence of packets, aid packet flow control, or provide error detection mechanisms such as checksums.
A checksum is an unsigned 16-bit value determined by performing 1's compliment addition on data within a packet. Typical packet receivers store packets to memory and then perform error checking functions including the calculation of the checksum. The calculation of checksums, however, can be time-consuming, thus slowing the processing of the packets and overall operation of the receivers.
The invention may be best understood by reading the disclosure with reference to the drawings, wherein:
Data verification or redundancy checking with checksums is commonly used to detect errors in data received from networks or peripheral devices. The addition of a checksum adder to a direct memory access (DMA) interface allows for the computation of checksums during direct memory access operations, thus reducing the latency incurred in the subsequent error detection. Embodiments of the present invention will now be described in more detail.
The DMA commands 102 include a source address field for specifying the source of data 104 to be loaded by the DMA interface 200, a destination address field for identifying the destination of the loaded data 104, and size fields for indicating the length of the data 104 to be accessed. The DMA commands 102 may include other fields and/or prompt other DMA interface 200 functionality, selected examples will be described below in detail.
The DMA interface 200 loads and stores control structures 106 that include information about the data 104 stored in memory 110, e.g., checksums or partial checksums of the data 104, gap variables indicating the validity of certain segments of the data 104, size parameters identifying the length of the data 104, and/or pointers to the locations in memory 110 where the data 104 is stored. The control structures 106 may be loaded or stored according to the same DMA commands 102 that direct the DMA interface 200 to load and store the data 104. For instance, in DMA reading operations, the DMA interface 200 may load a control structure 106 from memory 110 according to the one or more DMA commands 102, and subsequently load the data 104 according to the pointers within the control structure 106. In some embodiments the control structures 106 may be loaded or stored according to DMA commands 102 different from the DMA commands 102 that direct the DMA interface 200 to load and store the data 104.
The DMA interface 200 determines the checksums or partial checksums of the data 104 as the data 104 is stored to the memory 110. For instance, when storing data 104 according to DMA commands 102, a checksum adder 220 within the DMA interface 200 computes a checksum or partial checksums of the data 104. The computed checksum or partial checksums may be included in the control structures 106 to be stored to the memory 110. In some embodiments, the DMA commands 102 include a field to indicate whether the DMA interface 200 is to include certain segments of the data 104 during checksum computation. Thus the DMA interface 200 may selectively checksum segments of the data 104 according to the DMA commands 102 as the data 104 is being stored to memory 110. When the DMA interface 200 is to checksum data 104 that is less than a full data word used by the checksum adder 220, which may occur at the end of a data frame or when selectively checksumming segments of data 104, the DMA interface 200 may add padding to the data 104 in order to complete the data word.
Although
For descriptive convenience, the memory 110 is shown in
The DMA interface 200 includes a checksum adder 220 to determine a checksum 202 of loaded data 104. The DMA state machine 210 may provide the loaded data 104 to the checksum adder 220 in a store state. The checksum adder 220 includes a sum register 222 and an overflow register 224 used to compute the checksum 202 of the data 104. The checksum adder 220 performs a 1's compliment addition on the data 104 and stores the sum within the sum register 222 and an overflow, if present, to the overflow register 224. The checksum adder 210 adds the overflow and the sum to generate the checksum 202 and provides the computed checksum 202 to the DMA state machine 210. The DMA state machine 210 may store the checksum 202 to memory 110 according to DMA commands 102, or provide the checksum 202 to another DMA interface 200 for storing to memory 110.
The DMA interface 200 may determine partial checksums of the data 104 similarly to determining the entire checksum 202. For instance, the DMA state machine 210 provides portions of data 104 to checksum adder 220 to determine a checksum corresponding to those data portions. Since the determined checksum does not correspond to all of the data 104, it is a partial checksum. After the DMA interface 200 determines all of the partial checksums, they may be added to generate the checksum 202, or stored to memory 110 in a control structure 106.
The DMA interface 200 determines the checksum of the loaded data 104 with a checksum adder 220 as the data 104 is being stored to memory 112 by the DMA interface 200. The DMA interface 200 incorporates the checksum into a control structure 106 with other control fields, e.g., a pointer corresponding to the location of the data 104 in memory 112, and stores the control structure 106 to a memory 114. Although memories 112 and 114 are shown as distinct sets of contiguous addressable memory locations or distinct memory devices, they may be commingled or interweaved within any portion of memory 110.
The data flow in
The DMA interface 200 determines partial checksums of the data portions A-D with a checksum adder 220 as the data portions A-D are stored to memory 112 by the DMA interface 200. The DMA interface incorporates the partial checksums into a control structure 106 with other control fields, e.g., pointers corresponding to the locations of the data portions A-D in memory 112, and stores the control structure 106 to a memory 114. The control structure 106 may be stored to memory 114 after all of the partial checksums are computed, or stored after the first partial checksum is computed and subsequently updated with the computations of successive partial checksums.
According to next block 420, the DMA interface 200 loads data 104 according to the DMA commands 102. The DMA interface 200 may load data 104 from one or more of the devices 120_1 to 120_N or from memory 110 in response to the DMA commands 102. Depending on the size of the data 104 and the specifications of the system 100, the data 104 may be loaded in one DMA command 102 or with multiple DMA commands 102.
According to next block 430, the DMA interface 200 stores the loaded data 104 according to the DMA commands 102. The DMA interface 200 may store data 104 to one or more of the devices 120_1 to 120_N or to memory 110 in response to the DMA commands 102. Depending on the size of the data 104 and the specifications of the system 100, the data 104 may be loaded in one DMA command 102 or with multiple DMA commands 102. In blocks 420 and 430 when the data 104 is loaded and stored with multiple DMA commands, the DMA interface 200 may load and store a portion of the data 104 before the subsequent portion of data 104 is loaded and stored. Thus for a large data 104 segment, multiple load-store combinations may be used to transfer the packet between memory 110 and devices 120_1 to 120_N.
According to next block 440, the DMA interface 200 computes at least one checksum 202 of the data 104 as the DMA interface 200 stores the loaded data 104. The DMA interface 200 may include a checksum adder 220 to compute the checksum 202 of the data 104. When data 104 requires multiple DMA commands 102 to store the data 104, partial checksums of the data 104 may be computed by the DMA interface 200. These partial checksums, when added, result in the checksum 202 of the data 104.
According to next block 450, the DMA interface 200 stores the checksum 202 according to the DMA commands 102. When in block 440 the DMA interface 200 computes partial checksums, the partial checksums may be stored according to the DMA commands 102. The DMA interface 200 may store the checksum 202 or partial checksums by incorporating them in a control structure 106 and storing the control structure to memory 110 according to DMA commands 102.
Semantic processor 500 includes a direct execution parser (DXP) 550 that controls the processing of packets in the input buffer 530 and a semantic processing unit (SPU) 560 for processing segments of the packets or for performing other operations. The DXP 550 maintains an internal parser stack 551 of non-terminal (and possibly also terminal) symbols, based on parsing of the current input frame or packet up to the current input symbol. When the symbol (or symbols) at the top of the parser stack 551 is a terminal symbol, DXP 550 compares data DI at the head of the input stream to the terminal symbol and expects a match in order to continue. When the symbol at the top of the parser stack 551 is a non-terminal (NT) symbol, DXP 550 uses the non-terminal symbol NT and current input data DI to expand the grammar production on the stack 551. As parsing continues, DXP 550 instructs a SPU 560 to process segments of the input, or perform other operations.
Semantic processor 500 uses at least three tables. Code segments for SPU 560 are stored in semantic code table 556. Complex grammatical production rules are stored in a production rule table (PRT) 554. Production rule (PR) codes 553 for retrieving those production rules are stored in a parser table (PT) 552. The PR codes 553 in parser table 552 also allow DXP 550 to detect whether, for a given production rule, a code segment from semantic code table 556 should be loaded and executed by SPU 560.
The production rule (PR) codes 553 in parser table 552 point to production rules in production rule table 554. PR are stored, e.g., in a row-column format or a content-addressable format. In a row-column format, the rows of the table are indexed by a non-terminal symbol NT on the top of the internal parser stack 551, and the columns of the table are indexed by an input data value (or values) DI at the head of the input. In a content-addressable format, a concatenation of the non-terminal symbol NT and the input data value (or values) DI can provide the input to the parser table 552. Preferably, semantic processor 500 implements a content-addressable format, where DXP 550 concatenates the non-terminal symbol NT with 8 bytes of current input data DI to provide the input to the parser table 552. Optionally, parser table 552 concatenates the non-terminal symbol NT and 8 bytes of current input data DI received from DXP 550.
The semantic processor 500 includes a memory subsystem 570 for storing or augmenting segments of the packets. The memory system 570 includes the memory 110 to be accessed in direct memory access operations SPU 560. The SPU 560 includes a DMA interface 200 to directly access the memory 110 in response to DMA commands stored in the semantic code table 556. The SPU 560 may retrieve the DMA commands directly from the semantic code table 556 when prompted by the DXP 550, or they may be provided to the SPU 560 by the DXP 550 or a dispatcher (not shown) when multiple SPUs 550 are incorporated in semantic processor 500. The DMA commands 102 can be initiated according to the production rules output by PRT 554 pursuant to the parsing performed in parser table 552. The production rule 555 then launches SEP code in SCT 556 that contains the DMA commands 102 that cause the DMA interface 200 to automatically generate the checksum 202 and transfer the checksum to memory 110. The DMA commands, when executed, allow the SPU 560 to transfer data between the memory 110 and the input buffer 530, output buffer 540, or DXP 550.
The memory subsystem 570 includes a cryptography circuit 572 to perform cryptography operations on data, including encryption, decryption, and authentication, when directed by SPU 560. The cryptography circuit 572 includes a DMA interface 200 to directly access the memory 110 in response to DMA commands provided by the SPU 560. The DMA commands, when executed, allow the SPU 560 to transfer data between the memory 110 and the SPU 560, or to return the data to the memory 110.
One skilled in the art will recognize that the concepts taught herein can be tailored to a particular application in many other advantageous ways. In particular, those skilled in the art will recognize that the illustrated embodiments are but one of many alternative implementations that will become apparent upon reading this disclosure.
The preceding embodiments are exemplary. Although the specification may refer to “an”, “one”, “another”, or “some” embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment.